DDD في جوهر iGaming

منصة iGaming هي نظام نطاق معقد عند تقاطع التمويل والترفيه والامتثال. يساعد DDD في الحفاظ على التعقيد: يسلط الضوء على السياقات المحدودة، ويلتقط اللغة المنتشرة في كل مكان، ويحمي الثوابت بالمجمعات، ويبسط التكامل من خلال طبقات مكافحة الفساد، ويجعل سلوك النظام شفافًا من خلال أحداث المجال.

1) خريطة المجال والسياقات المحددة (التصميم الاستراتيجي)

• سياق اللاعب/KYC - التسجيل، التحقق، حدود اللعبة المسؤولة، حالات KYC/AML.
• سياق المحفظة/دفتر الأستاذ - الأرصدة والحجوزات والمعاملات والعملات المتعددة وأسعار الصرف.
• سياق الرهان - الرهانات/التذاكر، الزوج/النتائج، عروض الأسعار، التسوية، الإلغاء.
• سياق جولة الكازينو/اللعبة - جلسات، جولات، ظهور، تحكم RTP، حدود الرهان.
• المكافأة/سياق الترويج - قواعد المكافأة، الرهانات، الحصول على أموال المكافآت، مكافحة إساءة الاستخدام.
• سياق المخاطر/الاحتيال - التسجيل، الإشارات السلوكية، مشغلات القفل/المهلة.
• سياق المدفوعات - الودائع/عمليات السحب، وحالات بوابة الدفع، وأحداث استرداد التكاليف.
• سياق الامتثال/الإبلاغ - التقارير المقدمة إلى المنظمين، وقوائم الجزاءات، ومراجعة الحسابات.
• سياق تكامل المحتوى/المزود - التكامل مع مزودي الألعاب والكتالوجات والتكنولوجيا. ().
• التحليلات/نماذج القراءة - الإسقاطات والعروض لقراءات المنتج.

2) اللغة المنتشرة في كل مكان: جوهر المصطلحات

لاعب، جلسة، GameRound، Bet/Ticket،

دخول دفتر الأستاذ، عقد/احتياطي، تسوية،

ميزان المكافأة/المكافأة، متطلبات الرهان (Вейджер)،

مستوى KYC، الحد (الإيداع/الجلسة/الخسارة)، الاستبعاد الذاتي،

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

تستخدم هذه الأسماء بالتساوي في الرموز وقاعدة البيانات والوثائق والاختبارات والوصلات البينية.

3) المجاميع والثوابت (التصميم التكتيكي)

3. 1 محفظة (المجموع: «محفظة»)

• التوازن لا يذهب إلى المنطقة السلبية.
• الاحتياطي + المتاح ≤ مجموع الرصيد.
• الأسلاك ذرية وغبية (عن طريق 'التشغيل _ id').

• المحفظة. الاحتياطي (المبلغ، السبب، op_id) '→' WalletReserved '
• المحفظة. ارتكب (op_id) '→' WalletCommitted '
• المحفظة. التراجع (op_id) «→» WalletRolledBack

الحدود: المحفظة لا تعرف عن الرهان/المكافأة ؛ وهو يخدم معاملات النشر والاحتفاظ.

3. 2 الرهان/التذكرة (المجموع: «الرهان»)

• ولا يمكن قبول المعدل إلا في نافذة عرض الأسعار النشطة ؛ المبلغ ≤ حد اللاعب/الجلسة.
• بعد «تسوية»، يتم «الانتهاء» من الوضع ؛ ولا يسمح بإعادة الحساب إلا من خلال عمليات التعويض (الفراغ/إعادة الحساب) مع مراجعة واضحة للحسابات.

• 'الرهان. المكان (player_id، المبلغ، السعر، op_id) '→' BetPlaced '(требует Wallet. الاحتياطي)
• 'الرهان. تسوية (النتيجة، الدفع) "→" BetSettled "(يتطلب محفظة. الالتزام/الإصدار)
• 'الرهان. الفراغ (السبب) '→' BetVoided '

الحدود: الرهان لا «يصعد» إلى المحفظة - إنه يستدعي من خلال أوامر/تنسيق المجال.

3. 3 GameRound (المجموع: «الجولة»)

• كل دورة/جولة لها «جولة _ معرف» فريدة ومبلغ رهان/فوز مرتبط بها.
• لا تتجاوز نافذة RTP العتبات المحددة (على مستوى المزود + القواعد المحلية).

• جولة. بدأت '،' الجولة. راهن '،' الجولة. نتج «،» الجولة. مغلقة '.

3. 4 مكافأة (المجموع: «منحة إضافية»)

• ينخفض vager فقط من حجم الأعمال الصحيح، ولا تدخل عمليات شطب المكافآت في الخصم.
• لا يمكن شطب المكافآت والأموال الحقيقية في نفس الوقت وليس وفقًا لقاعدة الأولوية.

• «المكافأة الممنوحة» و «المكافأة المراهنة» و «المكافأة المنتهية الصلاحية» و «المكافأة المحولة».

4) التنسيقات والملاحم والاتساق

متزامن (CP): قبول الرهان واحتياطي الأموال - بطريقة واحدة: "الرهان. مكان '→' المحفظة. احتياطي '(عبر فريق النطاق/المنسق مع الموعد النهائي).
غير متزامن (المفوضية الأوروبية): حساب الأسعار، واستحقاق المكافأة، والتحليلات - من خلال الأحداث + صندوق الخروج.
متغير TCC: «TryReserve» (عقد)، «تأكيد» (التزام)، «إلغاء» (التراجع) للتأثيرات المالية.
الغباء: تحمل جميع الأوامر «عملية _ معرف»، المستهلكين - «صندوق الوارد».

5) طبقات مكافحة الفساد وعمليات التكامل

Provider ACL: ترجمة أحداث المزود «SpinResult' و» BonusWin «إلى» Round' الداخلية. نتج عن ذلك، «BonusWagered». المخططات والإصدارات داخل الرباط الصليبي الأمامي.
PSP ACL: تطبيع أوضاع الدفع، الخصوصية بواسطة psp _ tx _ id، التحويل إلى «LedgerEntry».
الامتثال: الإدماج في قوائم الجزاءات/برامج العمل الإقليمية - في سياق خارجي ؛ فقط «ScreeningUpdated» طبيعي الدخول إلى المجال.

القاعدة: القواميس/الأشكال الخارجية لا «تتسرب» إلى النواة.

6) الإسقاطات ونماذج القراءة

نموذج قراءة ملف تعريف اللاعب: حالات KYC، والحدود، والمكافآت النشطة، والمعاملات الجديدة.
نموذج قراءة الأرصدة: قراءة سريعة لواجهة المستخدم/التسويق ؛ المصدر - أحداث «المحفظة».
Bet History Read Model: Pagination by Date/Game; المصدر هو «BetPlaced/Settled».
تقارير الامتثال - الآراء المجسدة حسب المستأجر/الإقليم.

جميع التوقعات هي اضطرابات شديدة مع الإصدار و «مثل _ من/النضارة».

7) متعدد المستأجرين ومتعدد المناطق

وتحمل جميع الكيانات الرئيسية 'المستأجر - الهوية' و 'المنطقة' (إذا لزم الأمر).
حدود البيانات: لاعب، محفظة، رهانات - منطقة «الوطن» ؛ المجاميع/التقارير عبر الإقليمية فقط.
الإنصاف/الحصص: قيود على الفرق/الثانية وإعادة التوسيع على المستأجرين.
الإقامة/الامتثال: لا تغادر البيانات والمعاملات الشخصية المنطقة.

8) اختيار الاتساق (PACELC) حسب السياق

Wallet/Ledger - Strong/CP: المعاملات الخطية، نصاب السجلات.
قبول الرهان - التأكيد المتزامن (CP) + نماذج القراءة السريعة لواجهة المستخدم.
التسوية/المكافأة/التحليلات - المفوضية الأوروبية مع الدمج/التعويض الحتمي.
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"
}

• المخططات الخلفية/المستقبلية ؛ التطور عبر «مخطط _ نسخة».
• 'outbox' في معاملة مع تغييرات المجال ؛ النشر بواسطة الجزار مع التراجع.

10) مثال على تدفق «الرهان مع المكافأة» (تسلسل الكلمات)

1. 'الرهان. مكان '(فريق) → التحقق من حدود اللاعب وقواعد مكافأة محفظة →. Reserve (real + bonus _ equiv, op_id) '

2. "وضع الرهان" → قراءة تحديثات النموذج "Open Wagers'

3. ينشر المزود نتيجة جولة → → ACL. نتج عن ذلك "

4. يحسب المنسق: 'الرهان. تسوية (النتيجة، الدفع) محفظة «→». ارتكب (op_id)، وإذا فاز، فإن «BonusWagered» → تحويل محتمل للمكافأة إلى مكافآت حقيقية.
5. «BetSettled» → توقعات التاريخ والميزانية العمومية، التقارير.

11) سياسة الثوابت والاختبار

• مجموع «دخول دفتر الأستاذ» في المحفظة يساوي الرصيد ؛ لا توجد مخلفات سلبية.
• لا يمكنك قبول رهان مع استبعاد ذاتي نشط/حالة KYC المجمدة.
• يمكن أن ينخفض الرهان فقط ولا يتأرجح «في ناقص».
• لا تغير التسوية حالة المعدل النهائي بالفعل - فقط من خلال معاملة «الفراغ/Recalc» + التعويض.

• اختبارات قائمة على الملكية لثوابت المحفظة والرهانات.
• ملامح الفوضى: تأخيرات المزود، وفشل PSP، وصندوق الخروج/DLQ.
• التحكم في المخطط: هجرات الأحداث، توقعات الردم.

12) القياس عن بعد ومراجعة الحسابات

المقاييس: p95/p99 على PlaceBet/Reserve/Committet، حصة الإخفاقات حسب الحدود/ACC، معدل DLQ، إعادة زيادة النجاح، توقعات التأخير.
التعقب: يمتد إلى «komanda→agregat→outbox→konsyumer→proyektsiya»، «مستأجر - معرف»، «عملية - معرف»، «ملحمة _ معرف».
مراجعة الحسابات: سجل غير متغير لأنشطة المجال مشابه للمتطلبات التنظيمية.

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

جميع الأوامر مزودة بـ «عملية _ id» من أجل الخصوصية، والردود مع «as _ of »/« نسخة».

15) السلامة والامتثال

RLS/ACL: جميع الطلبات - في سياق «المستأجر _ id»، الوصول حسب الدور.
التقليل إلى أدنى حد: فصل أحداث المجال عن البيانات الشخصية ؛ إخفاء في DLQ/logs.
التقارير التنظيمية: التوقعات مع توقيعات التجزئة التي لا تتغير في النوافذ الزمنية.

16) أخطاء نموذجية

اتصال قوي بين السياقات (تعرف المحفظة الرهان/المكافأة مباشرة).
الكتابة المزدوجة إلى سياقات مختلفة بدون ملاحم/صندوق خارجي → عدم تطابق الأرصدة والأوضاع.
الافتقار إلى القيادة وخصوصية المستهلك → ازدواجية المعاملات/الحسابات.
تدفق عقود مقدمي الخدمات إلى نموذج المجال (من الأصعب الانتقال).
مجموع واحد «عملاق» (يتضمن اللاعب جميع) → قفل، وإنتاجية منخفضة.
لا توجد ثوابت واضحة - لا يمكن فحصها ومراقبتها.

17) وصفات سريعة

البدء: إصلاح حدود اللغة والسياق في كل مكان ؛ ثابتة.
المال: محفظة/ليدجر - CP، إدخالات النصاب القانوني، TCC للتأثيرات الخارجية.
الرهانات: الاستقبال المتزامن + الحساب غير المتزامن، كل ذلك من خلال الأحداث وصندوق الخروج ؛ الفراغ في كل مكان.
المكافآت: وحدة منفصلة ذات أولوية واضحة وشطب واضح.
عمليات التكامل: دائما عن طريق مخططات/إصدارات الرباط الصليبي الأمامي + ؛ لا توجد حمولات «خام» في القلب.
القراءات: إسقاطات/عروض عن الاحتياجات من المنتجات ؛ نضارة SLA + «as _ of».
التشغيل: مقاييس الثوابت، DLQ/إعادة صياغة كتب اللعب، إعادة بناء العروض.

18) قائمة مرجعية قبل البيع

• يتم تحديد السياقات المحدودة وعقودها (الأوامر/الأحداث).
• المجاميع لها ثوابت صريحة، وإصدار، وأوامر خفية.
• المعاملات النقدية - من خلال التعاون التقني/الصرامة في المعاملات ؛ تمكين مراجعة الحسابات.
• التكامل - عبر ACLs مع إصدار المخطط واختبارات التطور.
• نفذ outbox/inbox و DLQ وإعادة السحب الآمن.
• تنفذ الإسقاطات نضارة جيش تحرير السودان، وهناك مقاييس للتأخر/الصمود.
• يتم استيفاء الحصص/الحدود الخاصة بالمستأجرين المتعددين والإقامة في البيانات.
• إمكانية الرصد: تتبع «komanda→sobytiye→proyektsiya»، تنبيهات الثوابت.
• التوثيق: لغة المجال، مخططات السياق، كتب لعب الحوادث.

استنتاج

DDD في جوهر iGaming هو نظام فصل التعقيد: حدود السياق الواضحة، والتجمعات مع الثوابت، والأحداث كمصدر للحقيقة، و ACLs للتكامل الخارجي، وخيارات الاتساق المستنيرة. يجعل هذا النهج النظام الأساسي قابلاً للتطوير وموثوقًا به ومتوافقًا مع اللوائح، ويسرع من تطوير الميزات ويقلل من المخاطر التشغيلية - حتى مع النمو السريع لحركة المرور والجغرافيا وخطوط الإنتاج.