IGaming çekirdeğinde DDD

IGaming platformu finans, eğlence ve uyumun kesiştiği karmaşık bir alan sistemidir. DDD karmaşıklığı korumaya yardımcı olur: sınırlı bağlamları vurgular, her yerde bulunan dili yakalar, değişmezleri agregalarla korur, bozulmayı önleme katmanları aracılığıyla entegrasyonları basitleştirir ve sistem davranışını etki alanı olayları aracılığıyla şeffaf hale getirir.

1) Alan haritası ve sınırlı bağlamlar (stratejik tasarım)

• Oyuncu/KYC Bağlam - kayıt, doğrulama, sorumlu oyun sınırları, KYC/AML durumları.
• Cüzdan/Defter Bağlam - bakiyeler, rezervasyonlar, işlemler, çok para birimi, döviz kurları.
• Bahis Bağlamı - bahisler/biletler, çiftler/sonuçlar, teklifler, uzlaşma, iptal.
• Casino/Oyun Yuvarlak Bağlam - oturumlar, turlar, sırtlar, RTP kontrolü, bahis limitleri.
• Bonus/Promo Bağlam - bonus kuralları, bahisler, bonus fonları edinme, kötüye kullanım karşıtı.
• Risk/Dolandırıcılık Bağlamı - puanlama, davranışsal sinyaller, kilit/zaman aşımı tetikleyicileri.
• Ödemeler Bağlam - para yatırma/çekme, ödeme ağ geçidi durumları, ters ibraz olayları.
• Uyumluluk/Raporlama Bağlamı - düzenleyicilere raporlar, yaptırım listeleri, denetimler.
• İçerik/Sağlayıcı Entegrasyonu Bağlam - oyun sağlayıcıları, kataloglar, teknoloji ile entegrasyon. durumları.
• Analitik/Okuma Modelleri - ürün okumaları için projeksiyonlar ve vitrinler.

2) Her yerde bulunan dil: terimlerin çekirdeği

Oyuncu, Oturum, GameRound, Bahis/Bilet,

Defter girişi, Hold/Reserve, Settlement,

Bonus Kredi/Bonus Bakiyesi, Bahis Gereksinimi (Вейджер),

KYC Katmanı, Limit (depozito/oturum/kayıp), Kendini Dışlama,

Sağlayıcı Oyunu, RTP Penceresi, Risk Bayrağı, Uyumluluk Durumu.

Bu isimler kod, veritabanı, dokümantasyon, testler ve arayüzlerde eşit olarak kullanılır.

3) Agregalar ve değişmezler (taktik tasarım)

3. 1 Cüzdan (Toplam: 'Cüzdan')

• Denge negatif bölgeye girmez.
• Rezerv + toplam bakiye ≤ kullanılabilir.
• Kablolama atomik ve idempotenttir ('operation _ id'ile).

• 'Cüzdan. Rezerv (miktar, sebep, op_id) '-' WalletReserved '
• 'Cüzdan. Commit (op_id) '-' WalletCommitted '
• 'Cüzdan. Geri alma (op_id) '-' WalletRolledBack '

Border: Wallet, Bet/Bonus hakkında bilgi sahibi değildir; Gönderme ve rezerv işlemlerine hizmet eder.

3. 2 Bahis/Bilet (Toplam: 'Bahis')

• Oran sadece aktif teklif penceresinde kabul edilebilir; Miktar ≤ oyuncu/oturum sınırı.
• 'Yerleştikten' sonra statü 'kesinleşir'; Yeniden hesaplamaya yalnızca açık denetim ile telafi işlemleri (void/recalc) yoluyla izin verilir.

• 'Bet. Yer (player_id, miktar, fiyat, op_id) '-' BetPlaced '(требует Cüzdan. Rezerv)
• 'Bet. Settle (sonuç, ödeme) '-' BetSettled '(Cüzdan gerektirir. Commit/Release)
• 'Bet. Void (reason) '-' BetVoided '

Border: Bet, Wallet'a "tırmanmaz" - alan komutları/orkestrasyon yoluyla çağırır.

3. 3 GameRound (Toplam: 'Yuvarlak')

• Her spin/round benzersiz bir 'round _ id've ilişkili bir bahis/kazanç miktarına sahiptir.
• RTP penceresi belirtilen eşikleri aşmaz (sağlayıcı düzeyinde + yerel kurallarda).

• Yuvarlak. ',' Yuvarlak başladı. Staked ',' Round. Sonuç ',' Yuvarlak. Kapalı '.

3. 4 Bonus (Toplam: 'BonusGrant')

• Vager sadece geçerli cirodan azalır, bonus yazmaları borçlanmaya girmez.
• Öncelik kuralına göre değil, aynı zamanda bonus ve gerçek para yazmak mümkün değildir.

• 'BonusGranted', 'BonusWagered', 'BonusExpired', 'BonusConverted'.

4) Orkestrasyonlar, destanlar ve tutarlılık

Senkron (CP): Bahsin kabul edilmesi ve para rezervi - bir yol: 'Bahis. Yer '-' Cüzdan. Reserve '(son başvuru tarihi olan domain team/orchestrator aracılığıyla).
Asenkron (EC): oran hesaplama, bonus tahakkuk, analitik - olaylar + giden kutusu aracılığıyla.
TTK varyantı: Parasal etkiler için 'TryReserve' (hold), 'Confirm' (commit), 'Cancel' (rollback).
Idempotence: tüm komutlar 'operation _ id', tüketiciler - 'gelen kutusu' taşır.

5) Yolsuzlukla mücadele katmanları (ACL'ler) ve entegrasyonlar

Sağlayıcı ACL: sağlayıcı olaylarının çevirisi 'SpinResult', 'BonusWin' to internal 'Round. Sonuç ',' BonusWagered '. Şemalar ve versiyonlar ACL'nin içindedir.
PSP ACL: ödeme durumlarının normalleştirilmesi, 'psp _ tx _ id'ile idempotency,' LedgerEntry'e transfer.
Uyum ACL: yaptırım listeleri/RAP ile entegrasyon - dış bağlamda; Sadece normalleştirilmiş 'ScreeningUpdated' etki alanı içine almak.

Kural: Harici sözlükler/formatlar çekirdeğe "sızmaz".

6) Projeksiyonlar ve Okuma Modelleri

Oyuncu Profili Okuma Modeli: KYC durumları, limitler, aktif bonuslar, yeni işlemler.
Dengeler Okuma Modeli: UI/Pazarlama için Hızlı Okumalar; kaynak - 'Cüzdan' olayları.
Bahis Geçmişi Okuma Modeli: Tarihe/Oyuna Göre Pagination; Kaynak 'BetPlaced/Settled' şeklindedir.
Uyumluluk Raporları - Kiracı/Bölgeye Göre Maddeleştirilmiş Görünümler.

Tüm projeksiyonlar, sürüm oluşturma ve'as _ of/tazelik'ile idempotent yükselişlerdir.

7) Çok kiracı ve çok bölgeli

Tüm önemli varlıklar 'tenant _ id've (gerekirse)' bölge 'taşır.
Veri sınırları: oyuncu, cüzdan, bahisler -'ev "bölgesi; Yalnızca bölgeler arası kümeler/raporlar.
Adalet/kotalar: Ekipler/saniyeler üzerindeki sınırlar ve kiracılarda redrives.
İkamet/uygunluk: Kişisel veriler ve işlemler bölgeyi terk etmez.

8) Bağlam tarafından Tutarlılık Seçimi (PACELC)

Cüzdan/Defter - Güçlü/CP: doğrusallaştırılabilir işlemler, kayıtların nisabı.
Bahis kabulü - senkronize onay (CP) + UI için hızlı Okuma Modelleri.
Yerleşim/Bonus/Analytics - deterministik birleştirme/tazminat ile EC.
KYC/Uyumluluk - durumlar için EC olabilir, ancak "engelleme" kuralları eşzamanlı olarak uygulanır.

9) Etki Alanı Etkinlikleri: Sözleşmeler ve Sürüm

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

• Geri/ileri-compat şemaları; 'schema _ version' aracılığıyla evrim.
• Etki alanı değişiklikleri olan bir işlemde 'outbox'; Geri tepme ile butches tarafından yayın.

10) "Bonus ile Bahis" akışı örneği (kelime dizisi)

1. 'Bahis. Place '(takım) - Oyuncu limitlerini kontrol etme ve -' Cüzdan bonus kuralları. Rezerv (gerçek + bonus _ equiv, op_id) '

2. 'BetPlaced' - Model güncellemelerini oku 'Açık Bahisler'

3. Sağlayıcı sonucu yayınlar - Yuvarlak ACL. Sonuç '

4. Orkestratör hesaplar: 'Bahis. Settle (sonuç, ödeme) '-' Cüzdan. Commit (op_id)'ve kazanılırsa, 'BonusWagered' - bonusun gerçek olanlara olası bir dönüşümü.
5. 'BetSettled' - tarihin ve bilançoların projeksiyonları, raporlama.

11) Değişmezler ve test politikası

• Cüzdandaki tüm 'LedgerEntry' toplamı bakiyeye eşittir; Negatif artıklar yok.
• Aktif bir kendini dışlama/dondurulmuş KYC statüsüne sahip bir bahsi kabul edemezsiniz.
• Bahis sadece azalabilir ve "eksi'de sallanamaz.
• Uzlaşma, zaten kesinleşmiş olan oranın durumunu değiştirmez - sadece 'Void/Recalc' + mahsup işlemi yoluyla.

• Cüzdan değişmezlerinin ve bahislerin mülk tabanlı testleri.
• Kaosun konturları: sağlayıcı gecikmeleri, PSP arızaları, giden kutusu/DLQ redrives.
• Şema kontrolü: olay geçişleri, dolgu projeksiyonları.

12) Telemetri ve denetim

Metrikler: PlaceBet/Reserve/Commit'te p95/p99, limitler/ACC, DLQ oranı, redrive başarısı, gecikme projeksiyonları ile başarısızlık payı.
Tracing: spands "komanda _ agregat> outbox> konsyumer> proyektsiya", tags 'tenant _ id', 'operation _ id', 'saga _ id'.
Denetim: Düzenleyici gerekliliklerle karşılaştırılabilir etki alanı faaliyetlerinin değişmeyen bir günlüğü.

13) Depolama şeması (basitleştirilmiş)

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)

Agregalarda ('sürüm') sürüm oluşturma, rekabetçi kayıt sırasında kayıp güncellemeye karşı koruma sağlar.

14) Örnek Komut API'si (pseudo)

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

Tüm komutlar idempotency için 'operation _ id', yanıtlar'as _ of'/' version 'şeklindedir.

15) Güvenlik ve uyumluluk

RLS/ACL: tüm istekler - 'tenant _ id' bağlamında, role göre erişim.
PII-minimizasyon: alan olaylarının kişisel verilerden ayrılması; DLQ/günlüklerde maskeleme.
Düzenleyici raporlar: zaman pencerelerinde değişmeyen karma imzaları olan projeksiyonlar.

16) Tipik hatalar

Bağlamlar arasında güçlü bağlantı (Cüzdan doğrudan Bet/Bonus'u bilir).
Sagalar/giden kutusu olmadan farklı bağlamlara çift yazma - dengelerin ve durumların uyuşmazlığı.
Komut ve tüketici idempotency eksikliği - yinelenen işlemler/hesaplamalar.
Sağlayıcı sözleşmelerinin etki alanı modeline akışı (taşınması daha zordur).
Bir "dev" agrega (Oyuncu hepsini içerir) kilit, düşük verim.
Belirgin bir değişmezlik yoktur - kontrol edilemez ve izlenemezler.

17) Hızlı tarifler

Başlangıç: Ubiquitous Dil ve bağlam sınırlarını düzeltmek; belge değişmezleri.
Para: Cüzdan/Defter - CP, nisap girişleri, dış etkiler için TTK.
Bahisler: senkronize alım + asenkron hesaplama, tüm olaylar ve giden kutusu boyunca; idempotency her yerde.
Bonuslar: Net yazma-off önceliği ve vager ile ayrı birim.
Entegrasyonlar: her zaman ACL + şemaları/sürümleri aracılığıyla; Çekirdekte "ham" yük yok.
Okumalar: Ürün ihtiyaçlarına ilişkin projeksiyonlar/görüntüler; SLA tazeliği +'as _ of '.
Çalışma: değişmezlerin metrikleri, DLQ/redrave oyun kitapları, vitrinleri yeniden oluşturun.

18) Satış öncesi kontrol listesi

• Sınırlı bağlamlar ve sözleşmeleri (komutlar/olaylar) tanımlanmıştır.
• Agregaların açık değişmezleri, sürüm değiştirmeleri ve idempotent komutları vardır.
• Parasal işlemler - TTK/sıkı işlemsellik yoluyla; denetim etkinleştirildi.
• Entegrasyonlar - şema sürümleri ve evrim testleri ile ACL'ler aracılığıyla.
• Uygulanan giden kutusu/gelen kutusu, DLQ ve güvenli yeniden çizim.
• Projeksiyonlar SLA tazeliğini uygular, lag/staleness metrikleri vardır.
• Çok kiracılı kotalar/limitler ve veri ikameti karşılanır.
• Gözlemlenebilirlik: iz sürme "komanda ̇ sobytiye ̇ proyektsiya", değişmezler tarafından uyarılar.
• Dokümantasyon: alan dili, bağlam diyagramları, olay oyun kitapları.

Sonuç

IGaming çekirdeğindeki DDD, karmaşıklığın ayrılmasının bir disiplinidir: açık bağlam sınırları, değişmezlerle kümeler, bir gerçek kaynağı olarak olaylar, dış entegrasyonlar için ACL'ler ve bilinçli tutarlılık seçenekleri. Bu yaklaşım, platformu ölçeklenebilir, güvenilir ve düzenlemelere uygun hale getirir, özelliklerin geliştirilmesini hızlandırır ve trafiğin, coğrafyaların ve ürün gruplarının hızla büyümesiyle bile operasyonel riskleri azaltır.