iGaming ядросунда DDD

iGaming - бул каржы, оюн-зоок жана комплаенс кесилишиндеги татаал домен системасы. DDD кыйынчылыкты кармап турууга жардам берет: bounded contexts, ubiquitous тилди аныктайт, инварианттарды агрегаттар менен коргойт, коррупцияга каршы катмарлар аркылуу интеграцияны жөнөкөйлөтөт жана домендик окуялардын аркасында системанын жүрүм-турумун ачык-айкын кылат.

1) домен картасы жана bounded contexts (стратегиялык дизайн)

• Player/KYC Context - каттоо, текшерүү, жоопкерчиликтүү оюндун чектери, KYC/AML статусу.
• Wallet/Ledger Context - баланстар, камдар, зымдар, көп акча, курстар.
• Betting Context - коюмдар/билеттер, жубайлар/натыйжалары, котировкалар, эсептөө (settlement), жокко чыгаруу.
• Casino/Game Round Context - сессиялар, раунддар, спины, RTP контролдоо, чендер.
• Bonus/Promo Context - бонустардын эрежелери, vager, бонустук каражаттардын эквайрингдери, каршы кыянаттык.
• Тобокелдик/Fraud Context - скоринг, жүрүм-турум сигналдары, блокировка/тайм-ауттун триггерлери.
• Payments Context - депозиттер/корутундулар, төлөм шлюздарынын статусу, chargeback-окуялар.
• Compliance/Reporting Context - жөнгө салуучу органдарга отчеттор, санкциялык тизмелер, аудит.
• Content/Provider Integration Context - оюн провайдерлери менен интеграция, каталогдор, техникалык. статустары.
• Analytics/Read Models - азык-түлүк окуу үчүн проекциялар жана витриналар.

2) Ubiquitous тил: терминдердин өзөгү

Player (оюнчу), Session (сессия), GameRound (раунд), Bet/Ticket (коюм),

Ledger Entry (кабелдик), Hold/Reserve (камдык), Settlement (эсептөө),

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

KYC Tier, Limit (депозиттик/сессия/жоготуу), өз алдынча Exclusion,

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

Бул аталыштар коддо, DD, документтерде, тесттерде жана интерфейстерде бирдей колдонулат.

3) Агрегаттар жана башка (тактикалык дизайн)

3. 1 Wallet (Aggregate: `Wallet`)

• Баланс минуска кетпейт.
• Резерв + жеткиликтүү ≤ жалпы балансы.
• Өткөргүч атомардык жана идемпотенттик ('operation _ id' боюнча).

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

Чек ара: Wallet Bet/Bonus жөнүндө билбейт; ал зымдардын жана резервдердин операцияларын тейлейт.

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

• Коюм котировкалардын активдүү терезесинде гана кабыл алынышы мүмкүн; оюнчу/сессиянын ≤ лимитинин суммасы.
• Кийин "Settled" статусу "аяктады"; Кайра эсептөөгө так аудит менен компенсациялык операциялар (void/recalc) аркылуу гана жол берилет.

• `Bet. Place(player_id, amount, price, op_id)` → `BetPlaced` (требует Wallet. Reserve)
• `Bet. Settle (outcome, payout) '→' BetSettled '(Wallet талап кылат. Commit/Release)
• `Bet. Void(reason)` → `BetVoided`

Чек: Bet Кошелек "кирбейт" - домендик командалар/оркестр аркылуу колдонулат.

3. 3 GameRound (Aggregate: `Round`)

• Ар бир спин/раунд уникалдуу 'round _ id' жана байланыштуу сумма коюм/утуш бар.
• RTP терезе белгиленген чектен ашпайт (провайдердин деңгээлинде + жергиликтүү эрежелер).

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

3. 4 Bonus (Aggregate: `BonusGrant`)

• Вейджер валиддик жүгүртүүдөн гана азаят, бонусту эсептен чыгаруу дебетке кирбейт.
• Бонусту жана реалдуу каражаттарды артыкчылыктуу эрежеден тышкары бир убакта эсептен чыгаруу мүмкүн эмес.

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

4) Оркестр, дастандар жана ырааттуулук

Синхрондуу (CP): чендерди кабыл алуу жана каражаттарды камдоо - бир жол: 'Bet. Place` → `Wallet. Reserve '(домен командасы/мөөнөтү менен оркестратор аркылуу).
Асинхрондук (EC): чендерди эсептөө, бонустарды эсептөө, аналитика - окуялар + outbox аркылуу.
TCC параметр: 'TryReserve' (hold), 'Confirm' (commit), 'Cancel' (rollback) акча таасирлери үчүн.
Демпотенттик: бардык командалар 'operation _ id', консумерлер 'inbox'.

5) Коррупцияга каршы катмарлар (ACL) жана интеграция

Provider ACL: 'SpinResult', 'BonusWin' менен ички 'Round. Resulted`, `BonusWagered`. Схемалар жана версиялар - ACL ичинде.
PSP ACL: төлөм статусун нормалдаштыруу, 'psp _ tx _ id' демпотенттиги, 'LedgerEntry' котормосу.
Compliance ACL: санкциялардын тизмелери менен интеграциялоо/РЕР - тышкы контекстте; домендин ичине нормалдаштырылган 'ScreeningUpdated' гана кирет.

Эреже: тышкы сөздүктөр/форматтар ядронун ичине "кирбейт".

6) Проекциялар жана Read Models

Player Profile Read Model: KYC статусу, лимиттер, активдүү бонустар, жаңы бүтүмдөр.
Balances Read Model: UI/маркетинг үчүн тез окуу; булак - "Кошелек" окуялар.
Bet History Read Model: даталар/оюндар боюнча пагинация; булак - 'BetPlaced/Settled'.
Compliance Reports: Тенант/аймак боюнча материалдык түшүнүктөр.

Бардык проекциялар - 'as _ of/freshness' версиясы бар idempotent upsert's.

7) Көп-тенант жана көп-аймак

Бардык негизги жактар 'tenant _ id' жана (керек болсо) 'region' деп аталат.
Маалымат чектери: оюнчу, капчык, коюмдар - "үй" аймак; кросс-аймактык гана агрегаттар/отчеттор.
Fairness/квота: команда/сек лимиттери жана тенанттар боюнча редрайвалар.
Residency/комплаенс: жеке маалыматтар жана зымдар аймакты калтырбайт.

8) контексттер боюнча шайкештик тандоо (PACELC)

Wallet/Ledger - Strong/CP: сызыктуу өткөргүчтөр, жазуулардын өлчөмү.
Bet acceptance - синхрондуу ырастоо (CP) + UI үчүн тез Read Models.
Settlement/Bonus/Analytics - EC аныкталуучу өлчөө/ордун толтуруу менен.
KYC/Compliance - статустар үчүн EC болушу мүмкүн, бирок "бөгөт коюу" эрежелери синхрондуу колдонулат.

9) Домендик окуялар: келишимдер жана версия

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 схемалар; 'schema _ version' аркылуу эволюция.
• 'outbox' домендик өзгөрүүлөр менен транзакцияларда; backoff менен батч жарыялоо.

10) "Бонус менен коюм" агымынын мисалы (оозеки ырааттуулугу)

1. `Bet. Place '(команда) → оюнчунун чектерин жана бонус эрежелерин текшерүү →' Wallet. Reserve(real+bonus_equiv, op_id)`

2. 'BetPlaced' (окуя) → Read Model жаңылайт "Ачык коюмдар"

3. Провайдер жыйынтыкты жарыялайт → ACL → 'Round. Resulted`

4. Оркестр күтөт: 'Bet. Settle(outcome,payout)` → `Wallet. Commit (op_id) 'жана, утуп менен,' BonusWagered '→ реалдуу бонустун мүмкүн конверсиясы.
5. 'BetSettled' → тарыхтын жана баланстын проекциялары, отчеттуулук.

11) Инварианттар жана тестирлөө саясаты

• бардык 'LedgerEntry' капчык суммасы баланска барабар; терс калдыктары жок.
• Сиз активдүү өз алдынча exclusion/тоңдурулган KYC статусу менен коюмду кабыл алууга болбойт.
• Вейгер кичирейип, "минуска" ийилбейт.
• Settlement буга чейин бүтүп коюмдун статусун өзгөртпөйт - гана аркылуу 'Void/Recalc' + компенсациялык зым.

• Property-based капчык жана коюмдарды өзгөрүүсүз тесттер.
• Башаламандыктын контурлары: провайдердин кечигүүлөрү, PSP мүчүлүштүктөрү, outbox/DLQ redrayvs.
• Схемаларды көзөмөлдөө: окуялардын көчүрүү, backfill проекциялары.

12) Телеметрия жана аудит

Метрика: p95/p99 боюнча PlaceBet/Reserve/Commit, Limit/KUS боюнча мүчүлүштүктөрдүн үлүшү, DLQ rate, redrive success, lag проекциялары.
Tracing: уктап "команда → агрегат → outbox → consumer → проекция", tags 'tenant _ id', 'operation _ id', 'saga _ id'.
Аудит: жөнгө салуучу талаптар менен салыштырууга болот өзгөрүлбөс домендик иш-аракеттер журналы.

13) Сактоо схемасы (жөнөкөйлөштүрүлгөн)

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)

Агрегаттарда версиялоо ('version') атаандаштык жазууда жоготууларга каршы коргойт.

14) Мисалы API команда (псевдо)

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":"..." }

Бардык командалар - с 'operation _ id' демпотенттүүлүк үчүн, жооптор - с 'as _ of '/' version'.

15) Коопсуздук жана шайкештик

RLS/ACL: бардык суроолор - контекстинде 'tenant _ id', ролдорго жетүү.
PII-минималдаштыруу: жеке маалыматтардан домендик окуяларды бөлүү; DLQ/логтордо жашыруу.
Жөнгө салуучу отчеттор: убакыт терезелери боюнча өзгөрүлбөгөн хэш-кол менен проекциялар.

16) типтүү каталар

контексттердин ортосундагы күчтүү байланыш (Wallet түздөн-түз Bet/бонус билет).
Dual-write ар кандай контексттерде сагсыз/outbox → баланстарды жана статустарды туура эмес.
Командалардын жана консультанттардын жоктугу → кош зымдар/эсептөөлөр.
Домендик моделге провайдердик келишимдердин агымы (миграцияга өтүү кыйыныраак).
Бир "гигант" бирдиги (Player бардык камтыйт) → кулпу, төмөн throughput.
Эч кандай ачык инварианттар жок - аларды текшерүү жана көзөмөлдөө мүмкүн эмес.

17) Тез Recipes

Старт: Ubiquitous Тил жана контексттик чектерди бекитүү; инварианттарды документтештирүү.
Акча: Wallet/Ledger - CP, кворум жазуулар, тышкы таасирлер үчүн TCC.
Тарифтер: синхрондуу кабыл алуу + асинхрондук эсептөө, бардык окуялар жана outbox аркылуу; демпотенттик бардык жерде.
Бонустар: так эсептен чыгаруу артыкчылыгы жана вейджер менен өзүнчө агрегат.
Интеграция: ар дайым ACL + схемалар/версиялар аркылуу; эч кандай "чийки" негизги payload ".
Окуу: продукт муктаждыктарына проекциялары/витриналары; SLA сергектик + 'as _ of'.
Операция: инварианттардын метрикасы, DLQ/redrave playbook, rebuild витриналары.

18) Азык-түлүктүн алдындагы чек-тизме

• Аныкталган bounded contexts жана алардын келишимдери (команда/окуялар).
• Агрегаттар ачык-айкын инварианттар, нускалоо жана empotent буйрук бар.
• Акча операциялары - ТСС/катуу транзакциялуулук аркылуу; аудит киргизилген.
• Интеграциялоо - схемаларды версиялоо жана эволюциялык тесттер менен ACL аркылуу.
• Киргизилген outbox/inbox, DLQ жана коопсуз редрайв.
• Проекциялар SLA сергектигин ишке ашырат, lag/staleness метриктери бар.
• Көп-Тенантты квоталар/лимиттер жана data residency сакталат.
• байкоо: Trace "команда → окуя → проекция", инварианттар боюнча алерт.
• Документтер: домен тили, контекст диаграммалары, окуя ойнотмо.

Корутунду

iGaming ядросундагы DDD - бул татаалдыкты бөлүүнүн дисциплинасы: контексттердин так чектери, инварианттар менен агрегаттар, чындыктын булагы катары окуялар, тышкы интеграциялар үчүн ACL жана аң-сезимдүү шайкештик тандоосу. Мындай ыкма платформаны масштабдуу, ишенимдүү жана тиешелүү жөнгө салууларга айландырат, физиканы иштеп чыгууну тездетет жана операциялык тобокелдиктерди азайтат - трафиктин, географиялардын жана азык-түлүк линиясынын тез өсүшү менен да.