आईगेमिंग कोर में डीडीडी

IGaming प्लेटफ़ॉर्म वित्त, मनोरंजन और अनुपालन के चौराहे पर एक जटिल डोमेन सिस्टम है। डीडीडी जटिलता रखने में मदद करता है: बाध्य संदर्भों पर प्रकाश डालता है, सर्वव्यापी भाषा को कैप्चर करता है, आक्रमणकारियों को एकत्र करता है, भ्रष्टाचार विरोधी परतों के माध्यम से एकीकरण को सरल बनाता है, और डोमेन घटनाओं के माध्य बनाता है।

1) डोमेन मैप और बाउंडेड संदर्भ (रणनीतिक डिजाइन)

• खिलाड़ी/केवाईसी संदर्भ - पंजीकरण, सत्यापन, जिम्मेदार खेल सीमा, केवाईसी/एएमएल स्टेटस।
• बटुआ/लेजर संदर्भ - संतुलन, आरक्षण, लेनदेन, बहुसांस्कृतिक, विनिमय दर।
• सट्टेबाजी संदर्भ - दांव/टिकट, जोड़ी/परिणाम, उद्धरण, निपटान, रद्द करना।
• कैसीनो/गेम राउंड कॉन्फ्रेंस - सत्र, राउंड, बैक, आरटीपी नियंत्रण, सट्टेबाजी की सीमा।
• बोनस/प्रोमो संदर्भ - बोनस नियम, दांव, बोनस फंड प्राप्त करना, दुरुपयोग विरोधी।
• जोखिम/धोखाधड़ीसंदर्भ - स्कोरिंग, व्यवहार संकेत, लॉक/टाइमआउट ट्रिगर।
• भुगतान संदर्भ - जमा/निकासी, भुगतान प्रवेश द्वार स्थिति, चार्जबैक घटनाएं।
• अनुपालन/रिपोर्टिंग संदर्भ - नियामकों को रिपोर्ट, प्रतिबंध सूची, ऑडिट।
• सामग्री/प्रदाता एकीकरण संदर्भ - खेल प्रदाताओं, कैटलॉग, तकनीक के साथ एकीकरण। स्टेटस।
• एनालिटिक्स/रीड मॉडल - उत्पाद रीडिंग के लिए अनुमान और शोकेस।

2) सर्वव्यापी भाषा: शब्दों का मूल

खिलाड़ी, सत्र, गेमराउंड, बेट/टिकट,

लेजर एंट्री, होल्ड/रिजर्व, सेटलमेंट,

बोनस क्रेडिट/बोनस बैलेंस, वैगरिंग आवश्यकता (Вейджер),

केवाईसी टियर, सीमा (जमा/सत्र/हानि), स्व-बहिष्करण,

प्रदाता खेल, आरटीपी विंडो, जोखिम ध्वज, अनुपालन मामला।

इन नामों का उपयोग कोड, डेटाबेस, प्रलेखन, परीक्षण और इंटरफेस में समान रूप से किया जाता है।

3) एग्रीगेट्स और इनवेरिएंट्स (सामरिक डिजाइन)

3. 1 बटुआ (कुल्ला: 'बटुआ')

• संतुलन नकारात्मक क्षेत्र में नहीं जाता है।
• रिजर्व + उपलब्ध ≤ कुल संतुलन।
• वायरिंग परमाणु और पहचान है ('ऑपरेशन _ आईडी' द्वारा)।

• 'बटुआ। रिजर्व (राशि, कारण, op_id) '→' WalletReserved '
• 'बटुआ। कमिट (op_id) '→' वॉलेटकमेटी '
• 'बटुआ। रोलबैक (op_id) '→' WalletRoledBack '

सीमा: बटुआ बेट/बोनस के बारे में नहीं जानता है; यह पोस्टिंग और आरक्षित लेनदेन का कार्य करता

3. 2 बेट/टिकट (कुल: 'बेट')

• दर को केवल सक्रिय कोटेशन विंडो में स्वीकार किया जा सकता है; मात्रा ≤ प्लेयर/सत्र सीमा।
• 'सेटलमेंट' के बाद, स्थिति को 'अंतिम रूप' दिया गया है; स्पष्ट ऑडिट के साथ क्षतिपूर्ति संचालन (शून्य/पुनर्गणना) के माध्यम से ही पुनर्गणना की अनुमति है।

• 'शर्त। स्थान (player_id, राशि, मूल्य, op_id) '→' बेटप्लेस्ड '(требует बटुआ। रिजर्व)
• 'शर्त। सेटल करें (परिणाम, भुगतान) '→' बेटसेटेड '(बटुआ की आवश्यकता है। कमिट/रिलीज)
• 'शर्त। शून्य (कारण) '→' बेटवॉयड '

सीमा: बेट वॉलेट में "चढ़ाई" नहीं करता है - यह डोमेन कमांड/ऑर्केस्ट्रेशन के माध्यम से कहता है।

3. 3 गेमराउंड (एग्रीगेट: 'राउंड')

• प्रत्येक स्पिन/राउंड में एक अद्वितीय 'राउंड _ आईडी' और एक संबंधित शर्त/जीत राशि होती है।
• RTP विंडो निर्दिष्ट थ्रेसहोल्ड (प्रदाता स्तर + स्थानीय नियम पर) से अधिक नहीं है।

• 'राउंड। शुरू हुआ ',' राउंड। स्टेक्ड ',' राउंड। परिणामस्वरूप ',' राउंड। बंद '।

3. 4 बोनस (कुल: 'बोनसग्रांट')

• Vager केवल वैध टर्नओवर से कम हो जाता है, बोनस राइट-ऑफ डेबिट में नहीं जाता है।
• एक ही समय में बोनस और वास्तविक निधियों को प्राथमिकता नियम के अनुसार नहीं लिखना संभव नहीं है।

• 'BonusIfeded', 'BonusWagered', 'BonusExpired', 'BonusConverted'।

4) ऑर्केस्ट्रेशन, सागा और सुसंगतता

तुल्यकालिक (सीपी): शर्त की स्वीकृति और धन का भंडार - एक तरह से: 'बेट। '→' बटुआ रखें। रिजर्व '(समय सीमा के साथ डोमेन टीम/ऑर्केस्ट्रेटर के माध्यम से)

अतुल्यकालिक (EC): दर गणना, बोनस एक्रुअल, एनालिटिक्स - घटनाओं + आउटबॉक्स के माध्यम से।

टीसीसी संस्करण: मौद्रिक प्रभावों के लिए 'ट्रायरिजर्व' (पकड़), 'पुष्टि' (प्रतिबद्ध), 'रद्द' (रोलबैक)।

पहचान: सभी कमांड 'ऑपरेशन _ आईडी', उपभोक्ता - 'इनबॉक्स' ले जाते हैं।

5) भ्रष्टाचार विरोधी परतें (एसीएल) और एकीकरण

प्रदाता एसीएल: प्रदाता घटनाओं 'स्पिनरिजल्ट', 'बोनसविन' टू इंटरनल 'राउंड का अनुवाद। परिणामस्वरूप ',' BonusWagered '। स्कीमा और संस्करण एसीएल के अंदर हैं।

PSP ACL: भुगतान स्थितियों का सामान्यीकरण, 'psp _ tx _ id' द्वारा पहचान, 'LedgerEntry' में स्थानांतरित।

अनुपालन एसीएल: प्रतिबंधों की सूची/आरएपी के साथ एकीकरण - एक बाहरी संदर्भ में; केवल सामान्यीकृत 'स्क्रीनिंग अपडेटेड' डोमेन के अंदर मिलता है।

नियम: बाहरी शब्दकोश/प्रारूप कर्नेल में "लीक" नहीं होते हैं।

6) अनुमान और पढ़ें मॉडल

प्लेयर प्रोफाइल रीड मॉडल: केवाईसी स्टेटस, सीमाएं, सक्रिय बोनस, ताजा लेनदेन।

बैलेंस रीड मॉडल: यूआई/मार्केटिंग के लिए फास्ट रीड्स; स्रोत - 'बटुआ' घटनाएँ।

शर्त इतिहास पढ़ें मॉडल: तारीख/खेल द्वारा पृष्ठभूमि; स्रोत 'बेटप्लेस्ड/सेटेड' है।

अनुपालन रिपोर्ट - किरायेदार/क्षेत्र द्वारा भौतिक दृश्य।

सभी अनुमान वर्शनिंग और 'as _ of/treasness' के साथ निष्क्रिय अपसर्ट हैं।

7) बहु-किरायेदार और बहु-क्षेत्र

सभी प्रमुख इकाइयाँ 'किरायेदार _ आईडी' और (यदि आवश्यक हो) 'क्षेत्र' ले जाती हैं।

डेटा सीमाएँ: खिलाड़ी, बटुआ, दांव - "घर" क्षेत्र; क्रॉस-रीजनल एग्रीगेट/रिपोर्ट केवल।

निष्पक्षता/कोटा: टीमों/सेकंड पर सीमाएं और किरायेदारों पर पुनर्विकास।

रेजीडेंसी/अनुपालन: व्यक्तिगत डेटा और लेनदेन क्षेत्र को नहीं छोड़ ते हैं।

8) संदर्भ द्वारा संगति चयन (PACELC)

बटुआ/लेजर - मजबूत/सीपी: रैखिक लेनदेन, रिकॉर्ड का कोरम।

शर्त स्वीकृति - तुल्यकालिक पुष्टि (सीपी) + यूआई के लिए तेजी से पढ़ें मॉडल।

निपटान/बोनस/एनालिटिक्स - नियतात्मक विलय/मुआवजे के साथ ईसी।

KYC/अनुपालन - स्टेटस के लिए ईसी हो सकता है, लेकिन "अवरुद्ध" नियमों को तुल्यकालिक रूप से लागू किया जाता है।

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

• बैक/फॉरवर्ड-कॉम्पैट योजनाएं; 'स्कीमा _ संस्करण' के माध्यम से विकास।
• 'आउटबॉक्स' डोमेन परिवर्तनों के साथ एक लेनदेन; बैकऑफ के साथ कसाई द्वारा प्रकाशन।

10) "बेट विद बोनस" प्रवाह का उदाहरण (शब्द अनुक्रम)

1. 'बेट। प्लेस '(टीम) → प्लेयर लिमिट और →' वॉलेट बोनस नियम की जाँच कर रहा है। रिजर्व (वास्तविक + बोनस _ इक्विव, op_id) '

2. 'बेटप्लेस्ड' → पढ़ें मॉडल अपडेट 'ओपन वैगर्स'

3. प्रदाता परिणाम → → 'गोल एसीएल प्रकाशित करता है। परिणाम '

4. ऑर्केस्ट्रेटर गणना करता है: 'बेट। सेटल करें (परिणाम, भुगतान) '→' बटुआ। कमिट ( ) 'और, अगर जीता जाता है, तो' बोनस वेगर '- बोनस का वास्तविक रूपांतरण।

5. 'बेटसेटेड' - इतिहास और बैलेंस शीट के अनुमान, रिपोर्टिंग।

11) आक्रमणकारी और परीक्षण नीति

• बटुए में सभी 'LedgerEntre' का योग संतुलन के बराबर है; कोई नकारात्मक अवशेष नहीं
• आप सक्रिय आत्म-बहिष्करण/जमे हुए केवाईसी स्थिति के साथ शर्त स्वीकार नहीं कर सकते।
• दांव केवल कम हो सकता है और "माइनस में" स्विंग नहीं कर सकता है।
• निपटान पहले से ही अंतिम दर की स्थिति को नहीं बदलता है - केवल 'शून्य/पुनरावृत्ति' + ऑफसेटिंग लेनदेन के माध्यम से।

• वॉलेट अपरिवर्तनों और दांव के संपत्ति-आधारित परीक्षण।
• अराजकता के आधार: प्रदाता देरी, पीएसपी विफलताएं, आउटबॉक्स/डीएलक्यू रेड्रिव्स।
• स्कीमा नियंत्रण: घटना माइग्रेशन, बैकफिल अनुमान।

12) टेलीमेट्री और ऑडिटिंग

मेट्रिक्स: p95/p99 ऑन स्पॉटबेट/रिजर्व/कमिट, सीमा/एसीसी, डीएलक्यू दर, सफलता को फिर से लागू करना, अंतराल अनुमानों द्वारा विफलताओं का हिस्सा।

ट्रेसिंग: स्पैन "komanda→agregat→outbox→konsyumer→proyektsiya", टैग 'टेनेंट _ आईडी', 'ऑपरेशन _ आईडी', '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) उदाहरण कमांड एपीआई (छद्म)

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

सभी कमांड 'ऑपरेशन _ आईडी' के साथ पहचान के लिए हैं, प्रतिक्रियाएँ 'as _ of '/' संस्करण' के साथ हैं।

15) सुरक्षा और अनुपालन

RLS/ACL: सभी अनुरोध - 'किरायेदार _ id' के संदर्भ में, भूमिका द्वारा पहुंच।

पीआईआई-न्यूनतम करना: व्यक्तिगत डेटा से डोमेन घटनाओं का पृथक्करण; DLQ/लॉग में मास्किंग।

नियामक रिपोर्ट: समय खिड़कियों में अपरिवर्तनीय हैश हस्ताक्षर के साथ अनुमान।

16) विशिष्ट त्रुटियाँ

संदर्भों के बीच मजबूत कनेक्टिविटी (वॉलेट सीधे बेट/बोनस को जानता है)।

सागा/आउटबॉक्स के बिना विभिन्न संदर्भों में दोहरी लिखें - संतुलन और स्थिति का बेमेल।

कमांड और उपभोक्ता पहचान की कमी - डुप्लिकेट लेनदेन/गणना।

प्रदाता का प्रवाह डोमेन मॉडल में अनुबंध करता है (इसे पलायन करना अधिक कठिन है)।

एक "विशाल" कुल (खिलाड़ीमें सभी शामिल हैं) लॉक →, कम थ्रूपुट।

कोई स्पष्ट आक्रमणकारी नहीं हैं - उनकी जांच और निगरानी नहीं की जा सकती है।

17) त्वरित व्यंजनों

प्रारंभ: सर्वव्यापी भाषा और संदर्भ सीमाओं को ठीक करें; दस्तावेज़ अपरिवर्तनीय।

धन: बटुआ/लेजर - सीपी, कोरम प्रविष्टियाँ, बाहरी प्रभावों के लिए टीसीसी।

दांव: तुल्यकालिक स्वागत + अतुल्यकालिक गणना, सभी घटनाओं और आउटबॉक्स के माध्यम से; पहचान हर जगह है।

बोनस: स्पष्ट राइट-ऑफ प्राथमिकता और वेगर के साथ अलग इकाई।

एकीकरण: हमेशा एसीएल + योजनाओं/संस्करणों के माध्यम से; कोर में कोई "कच्चा" पेलोड नहीं।

रीडिंग: उत्पाद की जरूरतों पर अनुमान/प्रदर्शन; SLA ताजगी + 'के रूप में _'।

ऑपरेटिंग: इनवेरिएंट्स, डीएलक्यू/रिड्रेव प्लेबुक, पुनर्निर्माण शोकेस।

18) प्री-सेल चेकलिस्ट

• बंधे हुए संदर्भ और उनके अनुबंध (कमांड/इवेंट्स) परिभाषित किए गए हैं।
• एग्रीगेट्स में स्पष्ट अपरिवर्तनीय, वर्शनिंग और पहचानने वाले आदेश हैं।
• मौद्रिक लेनदेन - टीसीसी/सख्त लेनदेन के माध्यम से; ऑडिट सक्षम।
• एकीकरण - स्कीमा वर्शनिंग और विकास परीक्षणों के साथ एसीएल के माध्यम से।
• लागू आउटबॉक्स/इनबॉक्स, डीएलक्यू और सुरक्षित redraw।
• अनुमान एसएलए ताजगी को लागू करते हैं, अंतराल/गतिशीलता मैट्रिक्स हैं।
• बहु-किरायेदार कोटा/सीमाएं और डेटा निवास पूरे होते हैं।
• अवलोकन: "komanda→sobytiye→proyektsiya" का पता लगाना, आक्रमणकारियों द्वारा अलर्ट करता है।
• प्रलेखन: डोमेन भाषा, संदर्भ आरेख, घटना प्लेबुक।

निष्कर्ष

IGaming कोर में DDD जटिलता के पृथक्करण का एक अनुशासन है: स्पष्ट संदर्भ सीमाएं, आक्रमणकारियों के साथ समुच्चय, सत्य के स्रोत के रूप में घटनाएं, बाहरी एकीकरण के लिए ACL, और सूचित निरंतरता विकल। यह दृष्टिकोण मंच को स्केलेबल, विश्वसनीय और नियमों के अनुरूप बनाता है, सुविधाओं के विकास को गति देता है और परिचालन जोखिमों को कम करता है - यहां तक कि यातायात, भौगोलिक और उत्पाद लाइनों के तेजी से विकास के साथ।