iGaming yadrosidagi DDD

iGaming - bu moliya, oʻyin-kulgi va komplayens chorrahasidagi murakkab domen tizimi. DDD qiyinchiliklarni ushlab turishga yordam beradi: bounded contexts ajratadi, ubiquitous language tuzatadi, invariantlarni agregatlar bilan himoya qiladi, korrupsiyaga qarshi qatlamlar orqali integratsiyani soddalashtiradi va domen voqealari tufayli tizim xatti-harakatlarini shaffof qiladi.

1) Domen xaritasi va bounded contexts (strategik dizayn)

• Player/KYC Context - ro’yxatdan o’tish, tekshirish, mas’uliyatli o’yin limitlari, KYC/AML maqomlari.
• Wallet/Ledger Context - balanslar, zaxiralar, simlar, multivalyuta, kurslar.
• Betting Context - stavkalar/tiketlar, juft/natijalar, kotirovkalar, hisob-kitob (settlement), bekor qilish.
• Casino/Game Round Context - sessiyalar, raundlar, orqalar, RTP nazorati, stavkalar limitlari.
• Bonus/Promo Context - bonuslar, vager, bonus mablag’lari ekvayringlari, anti-abyuz qoidalari.
• Risk/Fraud Context - skoring, xulq-atvor signallari, blokirovka/taym-autlar triggeri.
• Payments Context - depozitlar/xulosalar, to’lov shlyuzlari maqomi, chargeback-hodisalar.
• Compliance/Reporting Context - regulyatorlarga hisobotlar, sanksiya ro’yxatlari, audit.
• Content/Provider Integration Context - oʻyin, katalog, texnik provayderlar bilan integratsiya. maqomlari.
• Analytics/Read Models - oziq-ovqat o’qish uchun proyeksiyalar va vitrinalar.

2) Ubiquitous language: atamalar yadrosi

Player (O’yinchi), Session (Sessiya), GameRound (Raund), Bet/Ticket (Stavka),

Ledger Entry (Simlar), Hold/Reserve (Zaxira), Settlement (Hisob-kitob),

Bonus Credit / Bonus Balance, Wagering Requirement (Вейджер),

KYC Tier, Limit (depozit/sessiya/yo’qotishlar), Self-Exclusion,

Provider Game, RTP Window, Risk Flag, Compliance Case.

Bu nomlar kod, DB, hujjatlar, testlar va interfeyslarda bir xil qo’llaniladi.

3) Agregatlar va invariantlar (taktik dizayn)

3. 1 Wallet (Aggregate: `Wallet`)

• Balans minusga aylanmaydi.
• Zaxira + mavjud ≤ umumiy balans.
• Atom va idempotent simlari (’operation _ id’bo’yicha).

• `Wallet. Reserve(amount, reason, op_id)` → `WalletReserved`
• `Wallet. Commit(op_id)` → `WalletCommitted`
• `Wallet. Rollback(op_id)` → `WalletRolledBack`

Chegarasi: Wallet Bet/Bonus haqida bilmaydi; u simlar va zaxiralar operatsiyalariga xizmat ko’rsatadi.

3. 2 Bet/Ticket (Aggregate: `Bet`)

• Stavka faqat aktiv kotirovka oynasida qabul qilinishi mumkin; o’yinchi/sessiya ≤ limiti summasi.
• «Settled» maqomidan keyin «yakunlangan»; qayta hisob-kitob qilishga faqat aniq auditga ega bo’lgan kompensatsiya operatsiyalari (void/recalc) orqali yo’l qo’yiladi.

• `Bet. Place(player_id, amount, price, op_id)` → `BetPlaced` (требует Wallet. Reserve)
• `Bet. Settle (outcome, payout)’→’BetSettled’(Wallet talab qiladi. Commit/Release)
• `Bet. Void(reason)` → `BetVoided`

Chegarasi: Bet Walletga «kirmaydi» - domen buyruqlari/orkestr orqali murojaat qiladi.

3. 3 GameRound (Aggregate: `Round`)

• Har bir spin/raund o’ziga xos’round _ id’ga va bog’liq stavka/yutuq summasiga ega bo’ladi.
• RTP oynasi belgilangan chegaradan oshmaydi (provayder darajasida + lokal qoidalar).

• `Round. Started`, `Round. Staked`, `Round. Resulted`, `Round. Closed`.

3. 4 Bonus (Aggregate: `BonusGrant`)

• Veyjer faqat valid aylanmasidan kamayadi, bonusni hisobdan chiqarish debetga kirmaydi.
• Bonus va real mablag’larni bir vaqtning o’zida ustuvorlik qoidasidan tashqari hisobdan chiqarish mumkin emas.

• `BonusGranted`, `BonusWagered`, `BonusExpired`, `BonusConverted`.

4) Orkestrlar, dostonlar va kelishuv

Sinxron (CP): stavkani qabul qilish va mablag’lar zaxirasi - yagona yo’l:’Bet. Place` → `Wallet. Reserve’(domen/orkestrator orqali).
Asinxron (EC): stavkani hisoblash, bonuslarni hisoblash, tahlillar - + outbox hodisalari orqali.
TCC varianti:’TryReserve’(hold),’Confirm’(commit),’Cancel’(rollback) pul effektlari uchun.
Idempotentlik: barcha buyruqlar’operation _ id’, konsumerlar’inbox’.

5) Korrupsiyaga qarshi qatlamlar (ACL) va integratsiya

Provider ACL: «SpinResult», «BonusWin» provayder voqealarini ichki’Roundga translyatsiya qilish. Resulted`, `BonusWagered`. Sxemalar va versiyalar - ACL ichida.
PSP ACL: to’lov maqomini normallashtirish,’psp _ tx _ id’bo’yicha idempotentlik,’LedgerEntry’ga tarjima qilish.
Compliance ACL: sanksiyalar/PER ro’yxatlari bilan tashqi kontekstda integratsiya qilish; domen ichiga faqat normallashtirilgan’ScreeningUpdated’kiradi.

Qoida: tashqi lugʻatlar/formatlar yadro ichiga «sizib chiqmaydi».

6) Proyeksiyalar va Read Models

Player Profile Read Model: KYC maqomi, limitlar, faol bonuslar, yangi tranzaksiyalar.
Balances Read Model: UI/marketing uchun tez o’qish; hodisa manbai - «Wallet».
Bet History Read Model: sana/o’yinlar bo’yicha paginatsiya; manba’BetPlaced/Settled’.
Compliance Reports: tenant/mintaqa boʻyicha materiallashtirilgan tasavvurlar.

Barcha proyeksiyalar idempotent upsert’va’as _ of/freshness’versiyasiga ega.

7) Ko’p tenant va ko’p mintaqa

Barcha asosiy narsalar’tenant _ id’va’region’.
Ma’lumotlar chegarasi: o’yinchi, hamyon, stavkalar - «uy» mintaqasi; kross-mintaqaviy faqat agregatlar/hisobotlar.
Fairness/kvotalar: team/sek uchun limitlar va tenantlar bo’yicha redrayvlar.
Residency/complayens: shaxsiy maʼlumotlar va simlar mintaqani tark etmaydi.

8) Kontekstlar bo’yicha muvofiqlikni tanlash (PACELC)

Wallet/Ledger - Strong/CP: lineirlangan simlar, yozuvlar kvorumi.
Bet acceptance - sinxron tasdiqlash (CP) + UI uchun tezkor Read Models.
Settlement/Bonus/Analytics - determinirlangan merge/kompensatsiyalar bilan EC.
KYC/Compliance - holatlar uchun EC boʻlishi mumkin, ammo «bloklash» qoidalari sinxron qoʻllaniladi.

9) Domen voqealari: shartnomalar va versiya

json
{
"event_id": "uuid",
"event_type": "BetPlaced",
"occurred_at": "timestamp",
"tenant_id": "T123",
"aggregate_id": "BET-...-UUID",
"version": 7,
"payload": { "...domain fields..." },
"schema_version": "v3"
}

• Back/forward-compat sxemalari; ’schema _ version’ orqali evolyutsiya.
• ’outbox’ domen o’zgarishlari bilan tranzaksiyada; backoff bilan nashr etish.

10) «Bonus bilan stavka» oqimi misoli (so’z ketma-ketligi)

1. `Bet. Place’(jamoa) → oʻyinchi limitlari va bonus qoidalarini tekshirish →’Wallet. Reserve(real+bonus_equiv, op_id)`

2.’BetPlaced’(hodisa) → Read Model «Ochiq stavkalar» ni yangilaydi

3. Provayder natijani e’lon qiladi → ACL →’Round. Resulted`

4. Orkestrator hisoblaydi:’Bet. Settle(outcome,payout)` → `Wallet. Commit (op_id)’i, agar g’olib bo’lsa,’BonusWagered’→ bonusni real holatga aylantirish mumkin.
5.’BetSettled’→ tarix va balanslar proyeksiyalari, hisobot.

11) Invariantlar va test siyosati

• Hamyon bo’yicha barcha’LedgerEntry’summasi balansga teng; salbiy qoldiqlar yo’q.
• Aktiv self-exclusion/muzlatilgan KYC holatida stavkani qabul qilish mumkin emas.
• Veyjer faqat kichrayishi va «minus» ga aylanmasligi mumkin.
• Settlement allaqachon yakunlangan stavkaning maqomini o’zgartirmaydi - faqat’Void/Recalc’+ kompensatsiya simlari orqali.

• Property-based hamyon invariantlari va stavkalar testlari.
• Xaos konturlari: provayderning kechikishlari, PSP nosozliklari, outbox/DLQ redrayvlari.
• Sxemalarni boshqarish: voqealar migratsiyasi, backfill proyeksiyalari.

12) Telemetriya va audit

Metrikasi: p95/p99 PlaceBet/Reserve/Commit, limit/KS, DLQ rate, redrive success, lag proyeksiyalari bo’yicha nosozliklar ulushi.
Treysing: «buyruq → agregat → outbox → konsumer → proyeksiya», teglar’tenant _ id’,’operation _ id’,’saga _ id’.
Audit: tartibga solish talablari bilan taqqoslanadigan oʻzgarmas domen harakatlari jurnali.

13) Saqlash sxemasi (soddalashtirilgan)

wallet(id, tenant_id, currency, balance, reserved, version)
ledger(id, wallet_id, amount, type, operation_id, occurred_at)
holds(id, wallet_id, amount, operation_id, expires_at, status)

bet(id, tenant_id, player_id, amount, price, status, placed_at, settled_at, operation_id)

bonus_grant(id, tenant_id, player_id, amount, wager_left, status, expires_at)

Agregatlarda versionlash (’version’) raqobat yozuvida lost update dan himoya qiladi.

14) Jamoalarning API namunasi (psevdo)

http
POST /bets. place
{
"tenant_id":"T1",
"player_id":"P42",
"amount":"10. 00",
"price":"2. 1",
"operation_id":"op-uuid",
"context":{"game_id":"g777","channel":"web"}
}
→ 202 Accepted + BetPlaced

POST /wallets. reserve
{ "wallet_id":"W1", "amount":"10. 00", "operation_id":"op-uuid", "reason":"bet" }
→ 200 { "reserved_balance":"..." }

Barcha buyruqlar - s’operation _ id’idempotentlik uchun, javoblar - s’as _ of ’/’ version’.

15) Xavfsizlik va muvofiqlik

RLS/ACL: barcha soʻrovlar’tenant _ id’kontekstida, rollar boʻyicha kirish.
PII-minimallashtirish: domen voqealarini shaxsiy ma’lumotlardan ajratish; DLQ/loglarda yashirish.
Tartibga soluvchi hisobotlar: vaqt oynalari bo’yicha o’zgarmas xesh-imzolari bo’lgan proyeksiyalar.

16) Tipik xatolar

Kontekstlar o’rtasidagi kuchli bog’liqlik (Wallet to’g’ridan-to’g’ri Bet/Bonusni biladi).
Dual-write turli kontekstlarda saqsiz/outbox → balans va maqomlarni muvofiqlashtirish.
Komandalar va konsumerlarning idempotentligi yo’qligi → o’tkazmalar/hisob-kitoblar dubli.
Provayder kontraktlarining domen modeliga o’tishi (migratsiya qilish qiyinroq).
Bitta «gigant» agregat (Player hamma narsani o’z ichiga oladi) → blokirovka, past throughput.
Aniq o’zgarishlar yo’q - ularni tekshirib, kuzatib bo’lmaydi.

17) Tezkor retseptlar

Boshlash: Ubiquitous Language va kontekst chegaralarini belgilang; invariantlarni hujjatlashtiring.
Pul: Wallet/Ledger - CP, kvorum yozuvlari, tashqi effektlar uchun TCC.
Stavkalar: sinxron qabul qilish + asinxron hisob-kitob, hammasi voqealar va outbox orqali; idempotentlik hamma joyda.
Bonuslar: hisobdan chiqarishning aniq ustuvorligi va veyjeri bo’lgan alohida agregat.
Integratsiya: har doim ACL + sxemalar/versiyalar orqali; yadroda «xomashyo» payload’lari yo’q.
O’qish: mahsulot ehtiyojlari uchun proyeksiyalar/vitrinalar; SLA yangilik +’as _ of’.
Operatsiya qilish: invariantlar metrikasi, DLQ/redrayv pleybuklar, rebuild vitrinalar.

18) Sotishdan oldingi chek-varaq

• Bounded contexts va ularning shartnomalari aniqlandi.
• Agregatlar aniq invariantlarga, versiyalashga va idempotent buyruqlariga ega.
• Pul operatsiyalari - TSS/qat’iy tranzaksion; audit kiritilgan.
• Integratsiyalar - sxemalar va evolyutsiya testlarini versiyalash bilan ACL orqali.
• outbox/inbox, DLQ va xavfsiz redraylar joriy etildi.
• Proyeksiyalar SLA yangiligini amalga oshiradi, lag/staleness metrikalari mavjud.
• Ko’p tenant kvotalar/limitlar va data residency rioya qilingan.
• Kuzatish: treysing «buyruq → hodisa → proyeksiya», invariantlar bo’yicha alertlar.
• Hujjatlar: domen tili, kontekstlar diagrammalari, hodisalar pleybuklari.

Xulosa

iGaming yadrosidagi DDD - murakkablikni ajratish intizomi: aniq kontekstlar chegarasi, invariantli agregatlar, haqiqat manbai sifatida voqealar, tashqi integratsiyalar uchun ACL va ongli ravishda muvofiqlikni tanlash. Bunday yondashuv platformani keng miqyosda, ishonchli va tartibga solishga mos qiladi, fichlarni ishlab chiqishni tezlashtiradi va hatto trafik, geografiya va mahsulot liniyasi tez o’sib borayotgan taqdirda ham operatsion xavflarni kamaytiradi.