DDD iGaming ბირთვში

iGaming პლატფორმა არის რთული დომენის სისტემა ფინანსთა, გართობისა და შესაბამისობის კვეთაზე. DDD ხელს უწყობს სირთულის შენარჩუნებას: განასხვავებს bounded contexts- ს, აფიქსირებს ubiquitous ენას, იცავს დანაყოფების ინვარიანტებს, ამარტივებს ინტეგრაციას ანტიკორუფციულ ფენებში და სისტემის ქცევას გამჭვირვალე ხდის აფეთქების შედეგად.

1) დომენების რუკა და bounded contexts (სტრატეგიული დიზაინი)

• Player/KYC Context - რეგისტრაცია, გადამოწმება, საპასუხისმგებლო თამაშის ლიმიტები, KYC/AML სტატუსები.
• Wallet/Ledger Context - ნაშთები, სარეზერვო, გაყვანილობა, მულტივალენტი, კურსები.
• Betting Context - განაკვეთები/თიკეტები, წყვილი/შედეგები, ციტატები, გაანგარიშება (გაანგარიშება), გაუქმება.
• Casino/Game Round Context - სესიები, რაუნდი, უკანა, RTP კონტროლი, განაკვეთების შეზღუდვები.
• Bonus/Promo Context - ბონუსის, ვაგონის, ბონუსის შეძენის წესები, ანტი-აბიუსი.
• Risk/Fraud Context - მორიელი, ქცევითი სიგნალები, ბლოკირების/დროის განტვირთვის გამომწვევი.
• Payments Context - ანაბრები/დასკვნები, გადახდის კარიბჭეების სტატუსები, chargeback მოვლენები.
• Compliance/Reporting Context - მოხსენებები რეგულატორებისთვის, სანქციების სიები, აუდიტი.
• შინაარსი/Provider Integration Context - ინტეგრაცია თამაშების პროვაიდერებთან, კატალოგებთან, ტექნიკასთან. სტატუსები.
• Analytics/Read Models - პროექციები და ფანჯრები სასურსათო კითხვისთვის.

2) Ubiquitous ენა: ტერმინების ბირთვი

პლეიერი (მოთამაშე), სესია (სესია), GameRound (რაუნდი), Bet/Ticket (შტაბი),

Ledger Entry (Stream), Hold/Reserve (რეზერვი), Settlement (გაანგარიშება),

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

KYC Tier, Limit (ანაბარი/სესია/ზარალი), Self-Exclusion,

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

ეს სახელები თანაბრად გამოიყენება კოდში, მონაცემთა ბაზაში, დოკუმენტაციაში, ტესტებში და ინტერფეისებში.

3) დანაყოფები და ინვარიანტები (ტაქტიკური დიზაინი)

3. 1 Wallet (Aggregate: `Wallet`)

• ბალანსი არ მიდის მინუსში.
• სარეზერვო + ხელმისაწვდომი არის საერთო ბალანსი.
• ატომური და idempotent- ის გაყვანილობა ('oporation _ 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) 'Bettled' (მოითხოვს Wallet). Commit/Release)
• `Bet. Void(reason)` → `BetVoided`

საზღვარი: Bet არ „ასვლის“ Wallet- ში - მიმართავს დომენის ბრძანებებს/ორკესტრებს.

3. 3 GameRound (Aggregate: `Round`)

• თითოეულ სპინ/რაუნდს აქვს უნიკალური 'round _ id "და დაკავშირებული განაკვეთის/მოგების ოდენობა.
• RTP ფანჯარა არ აღემატება მოცემულ ბარიერებს (პროვაიდერის დონეზე + ადგილობრივი წესები).

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

3. 4 Bonus (Aggregate: `BonusGrant`)

• Wager მცირდება მხოლოდ მოქმედი ბრუნვიდან, ბონუსის ჩამოწერა არ მიდის დებიუტში.
• შეუძლებელია ბონუსის და რეალური სახსრების ერთდროულად ჩამოწერა არა პრიორიტეტული წესით.

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

4) ორკესტრები, საგები და კოორდინაცია

სინქრონულად (CP): განაკვეთის მიღება და სახსრების რეზერვი - ერთი გზა: 'Bet. Place` → `Wallet. Reserve '(დომენის გუნდის/ორკესტრის მეშვეობით ვადაზე).
ასინქრონო (EC): განაკვეთების გაანგარიშება, ბონუსის დარიცხვა, ანალიტიკა - + გარე მოვლენების საშუალებით.
TCC ვერსია: 'TryReserve' (hold), 'Confirm' (commit), 'Cancel' (rollback) ფულადი ეფექტებისთვის.
Idempotenty: ყველა ბრძანება ატარებს 'operation _ id', კონსუტერები - 'inbox'.

5) ანტიკორუფციული ფენები (ACL) და ინტეგრაცია

Provider ACL: პროვაიდერის მოვლენების გადაცემა 'SpinResult', 'BonusWin' შიდა 'Round. Resulted`, `BonusWagered`. სქემები და ვერსიები - ACL- ის შიგნით.
PSP ACL: გადახდის სტატუსის ნორმალიზაცია, 'psp _ tx _ id' idempotence, თარგმნა 'LedgerEntry'.
კომპლექსი ACL: ინტეგრაცია სანქციების სიებთან/REP - გარე კონტექსტში; დომენში შედის მხოლოდ ნორმალიზებული 'ScreeningOnfated'.

წესი: გარე ლექსიკონები/ფორმატები არ „იჭრება“ ბირთვის შიგნით.

6) პროექცია და Read Models

Player Profile Read Model: KYC სტატუსები, ლიმიტები, აქტიური პრემიები, ახალი გარიგებები.
Balances Read Model: სწრაფი კითხვა UI/მარკეტინგისთვის; წყარო - 'Wallet' მოვლენები.
Bet History Read Model: თარიღების/თამაშების პაგინაცია; წყარო - 'BetPlaced/Settled'.
Compliance Reports: მატერიალიზებული წარმოდგენები ტენანტზე/რეგიონში.

ყველა პროექცია არის idempotent upsert ვერსიით და 'as _ of/freshness'.

7) მულტფილმები და მულტფილმის რეგიონი

ყველა საკვანძო ელემენტს აქვს 'tenant _ id' და (საჭიროების შემთხვევაში) 'region'.
მონაცემთა საზღვრები: მოთამაშე, საფულე, ფსონები - „საშინაო“ რეგიონი; ჯვარედინი რეგიონალური მხოლოდ აგრეგატები/მოხსენებები.
Fairness/კვოტები: გუნდური/წმ შეზღუდვები და ტენანტის რედაქცია.
Residence/შესაბამისობა: პირადი მონაცემები და გაყვანილობა არ ტოვებს რეგიონს.

8) თანმიმდევრულობის არჩევანი (PACELC) კონტექსტით

Wallet/Ledger - Strong/CP: ხაზოვანი გაყვანილობა, ჩანაწერების კვორუმი.
Bet acceptance - სინქრონული დადასტურება (CP) + სწრაფი Read Models UI- სთვის.
Settlement/Bonus/Analytics - EC დეტერმინისტული მერჯით/კომპენსაციით.
KYC/კომპლექსი - შეიძლება იყოს 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' ოდენობა ტოლია ბალანსზე; უარყოფითი ნარჩენები არ არსებობს.
• თქვენ არ შეგიძლიათ მიიღოთ კურსი აქტიური self-exclusion/გაყინული KYC სტატუსით.
• Wager შეიძლება მხოლოდ შემცირდეს და არ გადაიქცეს „მინუსში“.
• Settlement არ ცვლის უკვე დასრულებული განაკვეთის სტატუსს - მხოლოდ 'Void/Recalc' + საშუალებით ანაზღაურებადი გაყვანილობა.

• Property-based საფულეების და განაკვეთების ინვარიანტების ტესტები.
• ქაოსის კონტურები: პროვაიდერის შეფერხება, PSP წარუმატებლობა, Outbox/DLQ რადარები.
• სქემების კონტროლი: მოვლენების მიგრაცია, საბურავების პროგნოზები.

12) ტელემეტრია და აუდიტი

მეტრიკა: p95/p99 PlaceBet/Reserve/Commit, Limites/KUS, DLQ rate, redrive success, lag პროექციები.
ტრეიდინგი: სპანი „გუნდი - განყოფილება - outbox - კონსუტერის პროექცია“, ჭდეები '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)

დანაყოფების ვერსია ('ვერსია') დაიცავს კონკურენტუნარიანი ჩანაწერისთვის გრძელი განახლებისგან.

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

ყველა ბრძანება არის 'opotention _ id' idempotention- ით, პასუხები არის 'as _ of '/' version'.

15) უსაფრთხოება და შესაბამისობა

RLS/ACL: ყველა მოთხოვნა არის 'tenant _ id' კონტექსტში, როლების წვდომა.
PII მინიმიზაცია: დომენის მოვლენების განცალკევება პერსონალური მონაცემებიდან; შენიღბვა DLQ/ლოგებში.
მარეგულირებელი მოხსენებები: პროექცია უცვლელი ჰეშტის ხელმოწერებით დროის ფანჯრებზე.

16) ტიპიური შეცდომები

კონტექსტებს შორის ძლიერი კავშირი (Wallet- მა პირდაპირ იცის Bet/Bonus).
ორმაგი write სხვადასხვა კონტექსტში საგნების/outbox- ის გარეშე არის ბალანსებისა და სტატუსის შეუსაბამობა.
გუნდებისა და კონსიუმერების იდემპოტენტურობის არარსებობა წარმოადგენს გაყვანილობის/გამოთვლების დუბლებს.
პროვაიდერის კონტრაქტების მიმდინარეობა დომენის მოდელში (უფრო რთულია მიგრაცია).
ერთი „გიგანტური“ ერთეული (Player მოიცავს ყველაფერს) ბლოკირება, დაბალი throughput.
აშკარა ინვარიანტები არ არსებობს - მათი შემოწმება და მონიტორინგი შეუძლებელია.

17) სწრაფი რეცეპტები

დასაწყისი: ჩაწერეთ Ubiquitous ენა და კონტექსტური საზღვრები; შეადგინეთ ინვარიანტები.
ფული: Wallet/Ledger - CP, კვორუმის ჩანაწერები, TCC გარე ეფექტებისთვის.
ფსონები: სინქრონული მიღება + ასინქრონული გაანგარიშება, ყველაფერი მოვლენებისა და გარედან; იდემპოტენტობა ყველგან.
პრემიები: ცალკეული განყოფილება, რომელსაც აქვს ჩამოწერის მკაფიო პრიორიტეტი და ვეგერი.
ინტეგრაცია: ყოველთვის ACL + სქემების/ვერსიების საშუალებით; ბირთვში არ არის „სასაქონლო“ payload.
კითხვა: პროექციები/ფანჯრები პროდუქტის საჭიროებებზე; SLA სიახლე + 'as _ of'.
ოპერაცია: ინვარიანტების მეტრიკა, DLQ/playbucks redrive, rebuild ფანჯარა.

18) ჩეკის სია გაყიდვამდე

• განისაზღვრება bounded contexts და მათი კონტრაქტები (გუნდები/მოვლენები).
• დანაყოფებს აქვთ აშკარა ინვარიანტები, ვერსიები და idempotent ბრძანებები.
• ფულადი ოპერაციები - TSS/მკაცრი გარიგების საშუალებით; აუდიტი ჩართულია.
• ინტეგრაცია - ACL- ის საშუალებით, სქემების და ევოლუციის ტესტების ვერსიით.
• დაინერგა outbox/inbox, DLQ და უსაფრთხო რადარი.
• პროექციები ახორციელებს SLA სიახლეს, არის მეტრიკა lag/staleness.
• დაიცვა მულტფილმის-ჩრდილოვანი კვოტები/ლიმიტები და მონაცემთა დათმობა.
• დაკვირვება: ტრეისი „გუნდი - მოვლენა - პროექცია“, ალერტები ინვარიანტებისთვის.
• დოკუმენტაცია: დომენის ენა, კონტექსტის დიაგრამები, ინციდენტების პლეიბუკები.

დასკვნა

IGaming ბირთვში DDD არის სირთულის განცალკევების დისციპლინა: მკაფიო კონტექსტის საზღვრები, ინვარიანტების აგრეგატები, მოვლენები, როგორც ჭეშმარიტების წყარო, ACL გარე ინტეგრაციისთვის და თანმიმდევრულობის შეგნებული არჩევანი. ეს მიდგომა პლატფორმას ხდის ფართომასშტაბიანი, საიმედო და შესაბამისი რეგულაციებისთვის, აჩქარებს წინსვლის განვითარებას და ამცირებს ოპერაციულ რისკებს - თუნდაც ტრაფიკის, გეოგრაფიული და პროდუქტის ხაზის სწრაფი ზრდით.