iGaming nüvəsində DDD

iGaming platforması maliyyə, əyləncə və komplayens qovşağında mürəkkəb bir domen sistemidir. DDD çətinliyi saxlamağa kömək edir: bounded contexts, ubiquitous language qeyd edir, invariantları aqreqatlarla qoruyur, antikorrupsiya təbəqələri ilə inteqrasiyanı asanlaşdırır və domen hadisələri ilə sistemin davranışını şəffaf edir.

1) Domen xəritəsi və bounded contexts (strateji dizayn)

• Player/KYC Context - qeydiyyat, yoxlama, məsuliyyətli oyun limitləri, KYC/AML statusları.
• Wallet/Ledger Context - balans, rezervasiya, kabel, multi-valyuta, kurslar.
• Betting Context - dərəcələr/biletlər, cütlük/nəticələr, kotirovkalar, hesablaşma (settlement), ləğv.
• Casino/Game Round Context - sessiyalar, raundlar, arxalar, RTP nəzarəti, bahis limitləri.
• Bonus/Promo Context - bonus qaydaları, vager, bonus vəsaitlərinin ekvayrinqi, anti-sui-istifadə.
• Risk/Fraud Context - skoring, davranış siqnalları, kilidləmə/zaman aşma tetikləyiciləri.
• Payments Context - depozitlər/çıxışlar, ödəniş şlüzlərinin statusları, chargeback hadisələri.
• Compliance/Reporting Context - tənzimləyicilərə hesabatlar, sanksiya siyahıları, audit.
• Content/Provider Integration Context - oyun provayderləri, kataloqlar, texniki ilə inteqrasiya. statuslar.
• Analytics/Read Models - məhsul oxu üçün proyeksiyalar və vitrinlər.

2) Ubiquitous language: terminlərin nüvəsi

Player, Session, GameRound, Bet/Ticket,

Ledger Entry, Hold/Reserve, Settlement,

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

KYC Tier, Limit (depozit/sessiya/itki), Öz-Exclusion,

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

Bu adlar kod, DB, sənədləşmə, test və interfeyslərdə eyni şəkildə istifadə olunur.

3) Aqreqatlar və invariantlar (taktiki dizayn)

3. 1 Wallet (Aggregate: `Wallet`)

• Balans mənfi getmir.
• Ehtiyat + mövcud ≤ ümumi balans.
• Atomar və idempotent ('operation _ id').

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

Sərhəd: Wallet Bet/Bonus haqqında bilmir; o, naqil və ehtiyat əməliyyatlarına xidmət edir.

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

• Bahis yalnız aktiv kotirovka pəncərəsində qəbul edilə bilər; oyunçu/sessiya ≤ limitinin məbləği.
• «Settled» statusundan sonra «başa çatdı»; təkrar hesablama yalnız dəqiq auditlə kompensasiya əməliyyatları (void/recalc) vasitəsilə icazə verilir.

• `Bet. Place(player_id, amount, price, op_id)` → `BetPlaced` (требует Wallet. Reserve)
• `Bet. Settle (outcome, payout) '→' BetSettled '(Wallet tələb edir. Commit/Release)
• `Bet. Void(reason)` → `BetVoided`

Sərhəd: Bet «dırmaşır» Wallet - domen komandaları/orkestr vasitəsilə müraciət.

3. 3 GameRound (Aggregate: `Round`)

• Hər spin/raund unikal 'round _ id' və bağlı məbləği bahis/uduş var.
• RTP pəncərəsi müəyyən edilmiş həddi aşmır (provayder səviyyəsində + yerli qaydalar).

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

3. 4 Bonus (Aggregate: `BonusGrant`)

• Veycer yalnız valid dövriyyəsindən azalır, bonusun silinməsi debet deyil.
• Prioritet qaydadan kənar bonus və real vəsaitləri eyni vaxtda çıxmaq mümkün deyil.

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

4) Orkestrlər, dastanlar və uyğunluq

Sinxron (CP): dərəcənin qəbulu və vəsait ehtiyatı - vahid yol: 'Bet. Place` → `Wallet. Reserve '(domen komandası/orkestrator ilə).
Asinxron (EC): dərəcənin hesablanması, bonusların hesablanması, analitika - hadisələr + outbox vasitəsilə.
TCC variantı: pul effektləri üçün 'TryReserve' (hold), 'Confirm' (commit), 'Cancel' (rollback).
İdempotentlik: bütün komandalar 'operation _ id', konsumerlər 'inbox' daşıyır.

5) Antikorrupsiya təbəqələri (ACL) və inteqrasiya

Provider ACL: «SpinResult», «BonusWin» provayder hadisələrinin daxili 'Roundda yayımlanması. Resulted`, `BonusWagered`. Sxemlər və versiyalar - ACL daxilində.
PSP ACL: ödəniş statuslarının normallaşdırılması, 'psp _ tx _ id' üzrə idempotentlik, 'LedgerEntry' -ə tərcümə.
Compliance ACL: sanksiyalar siyahıları ilə inteqrasiya/RER - xarici kontekstdə; Domen daxilinə yalnız normallaşdırılmış 'ScreeningUpdated' daxil olur.

Qayda: xarici lüğətlər/formatlar nüvənin içərisinə sızmır.

6) Proyeksiyalar və Read Models

Player Profile Read Model: KYC statusları, limitlər, aktiv bonuslar, təzə əməliyyatlar.
Balances Read Model: UI/marketinq üçün sürətli oxu; mənbə - «Wallet» hadisələr.
Bet History Read Model: tarixlərə/oyunlara görə paginasiya; mənbə - 'BetPlaced/Settled'.
Compliance Reports: Tenant/region üzrə materiallaşdırılmış təsəvvürlər.

Bütün proyeksiyalar «as _ of/freshness» versiyalı idempotent upsert 'dir.

7) Multi-tenant və multi-region

Bütün əsas varlıqlar 'tenant _ id' və (lazım olduqda) 'region' daşıyır.
Məlumat sərhədləri: oyunçu, pul kisəsi, bahislər - «ev» bölgəsi; cross-regional yalnız aqreqatlar/hesabatlar.
Fairness/kvotalar: komanda/san limitləri və tenant redrayvlar.
Residency/complayens: şəxsi məlumatlar və kabellər bölgəni tərk etmir.

8) Kontekstlərə görə uyğunluq seçimi (PACELC)

Wallet/Ledger - Strong/CP: lineer naqillər, qeydlərin kvorumu.
Bet acceptance - sinxron təsdiq (CP) + UI üçün sürətli Read Models.
Settlement/Bonus/Analytics - determinated merge/kompensasiya ilə EC.
KYC/Compliance - statuslar üçün EC ola bilər, lakin «bloklama» qaydaları sinxron tətbiq olunur.

9) Domen hadisələri: müqavilələr və 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 sxemləri; 'schema _ version' vasitəsilə təkamül.
• domen dəyişiklikləri ilə əməliyyatlarda 'outbox'; backoff ilə batches nəşr.

10) «Bonus ilə bahis» axını nümunəsi (söz ardıcıllığı)

1. `Bet. Place '(komanda) → oyunçu limitlərinin və bonus qaydalarının yoxlanılması →' Wallet. Reserve(real+bonus_equiv, op_id)`

2. 'BetPlaced' (hadisə) → Read Model yeniləyir «Açıq bahislər»

3. Provayder nəticəni dərc edir → ACL → 'Round. Resulted`

4. Orkestrator hesab edir: 'Bet. Settle(outcome,payout)` → `Wallet. Commit (op_id) 'və, qalib gəldikdə,' BonusWagered '→ real bonus mümkün dönüşüm.
5. 'BetSettled' → tarix və balans proyeksiyaları, hesabat.

11) İnvariantlar və test siyasəti

• Bütün 'LedgerEntry' cüzdan məbləği balansa bərabərdir; mənfi qalıqlar yoxdur.
• Aktiv self-exclusion/dondurulmuş KYC statusu ilə bahis qəbul edilə bilməz.
• Veycer yalnız kiçildilə bilər və «mənfi» yellənə bilməz.
• Settlement artıq bitmiş bahis statusunu dəyişdirmir - yalnız 'Void/Recalc' + kompensasiya naqili vasitəsilə.

• Property-based cüzdan invariantları və bahis testləri.
• Xaos konturları: provayder gecikmələri, PSP nasazlıqları, outbox/DLQ redrayları.
• Sxemlərə nəzarət: hadisələrin miqrasiyası, backfill proyeksiyaları.

12) Telemetriya və audit

Metriklər: PlaceBet/Reserve/Commit-də p95/p99, limit uğursuzluqlarının nisbəti/KUS, DLQ rate, redrive success, lag proyeksiyaları.
Trace: «komanda → yığma → outbox → konsumer → proyeksiya», tags 'tenant _ id', 'operation _ id', 'saga _ id'.
Audit: tənzimləmə tələbləri ilə müqayisə edilə bilən dəyişməz domen fəaliyyət jurnalı.

13) Saxlama sxemi (sadələşdirilmiş)

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)

Aqreqatlarda versiya ('version') rəqabətli qeyd zamanı lost update-dən qoruyacaq.

14) API komanda nümunəsi (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":"..." }

Bütün komandalar - s 'operation _ id' idempotentlik üçün, cavablar - s 'as _ of '/' version'.

15) Təhlükəsizlik və uyğunluq

RLS/ACL: Bütün sorğular - 'tenant _ id' kontekstində, rollara daxil olmaq.
PII-minimallaşdırma: domen hadisələrinin şəxsi məlumatlardan ayrılması; DLQ/log maskası.
Tənzimləyici hesabatlar: zaman pəncərələrində dəyişməz hash imzaları olan proyeksiyalar.

16) Tipik səhvlər

Kontekstlər arasında güclü əlaqə (Wallet birbaşa Bet/Bonus bilir).
Dual-write/outbox → balans və status uyğunsuzluq olmadan müxtəlif kontekstlərdə.
Komandaların və konsumerlərin idempotentliyinin olmaması → qoşa naqillər/hesablamalar.
Domen modelinə provayder müqavilələrinin axını (miqrasiya etmək daha çətindir).
Bir «nəhəng» aqreqat (Player bütün daxildir) → kilid, aşağı throughput.
Aşkar invariantlar yoxdur - onları yoxlamaq və izləmək mümkün deyil.

17) Sürətli reseptlər

Başlanğıc: Ubiquitous Language və kontekst sərhədlərini düzəldin; invariantları sənədləşdirin.
Pul: Wallet/Ledger - CP, kvorum qeydləri, xarici effektlər üçün TCC.
Bahislər: sinxron qəbul + asenxron hesablama, bütün hadisələr və outbox vasitəsilə; idempotentlik hər yerdə.
Bonuslar: Dəqiq silinmə prioriteti və veycer ilə ayrı bir aqreqat.
Inteqrasiya: həmişə ACL + sxemləri/versiyası vasitəsilə; nüvədə heç bir «xammal» payload.
Oxu: məhsulun ehtiyaclarına proyeksiyalar/vitrinlər; SLA təravət + 'as _ of ".
Əməliyyat: invariant metrikası, DLQ/redrave playbook, rebuild vitrin.

18) Satış öncəsi yoxlama siyahısı

• Bounded contexts və onların müqavilələri (komandalar/hadisələr) müəyyən edilmişdir.
• Aqreqatlar açıq invariantlara, versiyalara və idempotent komandalara malikdir.
• Pul əməliyyatları - TSS/ciddi əməliyyat vasitəsilə; audit daxildir.
• İnteqrasiya - sxemlərin versiyalaşdırılması və təkamül testləri ilə ACL vasitəsilə.
• outbox/inbox, DLQ və təhlükəsiz redrave tətbiq.
• Proyeksiyalar SLA təravətini həyata keçirir, lag/staleness metrikləri var.
• Multi-tenant kvotalar/limitlər və data residency riayət olunur.
• Müşahidə: treysinq «komanda → hadisə → proyeksiya», invariantlara görə alert.
• Sənədləşmə: domen dili, kontekstlərin diaqramları, hadisələrin playbukları.

Nəticə

iGaming nüvəsindəki DDD bir çətinlik ayırma intizamıdır: aydın kontekstlər sərhədləri, invariantlı aqreqatlar, həqiqət mənbəyi kimi hadisələr, xarici inteqrasiyalar üçün ACL və şüurlu uyğunluq seçimi. Bu yanaşma platformanı miqyaslı, etibarlı və tənzimləməyə uyğun edir, fiqurların inkişafını sürətləndirir və əməliyyat risklərini azaldır - hətta trafikin, coğrafiyanın və məhsul xəttinin sürətlə artması ilə belə.