DDD در هسته iGaming

پلت فرم iGaming یک سیستم دامنه پیچیده در تقاطع مالی، سرگرمی و انطباق است. DDD به حفظ پیچیدگی کمک می کند: زمینه های محدود را برجسته می کند، زبان همه جا را ضبط می کند، از یکپارچه ها با aggregates محافظت می کند، ادغام را از طریق لایه های ضد فساد ساده می کند و رفتار سیستم را از طریق رویدادهای دامنه شفاف می کند.

1) نقشه دامنه و زمینه های محدود (طراحی استراتژیک)

• زمینه بازیکن/KYC - ثبت نام، تأیید، محدودیت بازی مسئول، وضعیت KYC/AML.
• کیف پول/لجر زمینه - تعادل، رزرو، معاملات، چند ارزی، نرخ ارز.
• شرط بندی زمینه - شرط/بلیط, جفت/نتایج, نقل قول, حل و فصل, لغو.
• کازینو/بازی دور زمینه - جلسات، دور، پشت، کنترل RTP، محدودیت شرط بندی.
• پاداش/زمینه تبلیغاتی - قوانین پاداش، شرط بندی، کسب بودجه پاداش، ضد سوء استفاده.
• ریسک/تقلب زمینه - به ثمر رساند, سیگنال های رفتاری, قفل/وقفه باعث.
• زمینه پرداخت - سپرده ها/برداشت ها، وضعیت های دروازه پرداخت، رویدادهای بازپرداخت.
• انطباق/گزارش زمینه - گزارش به تنظیم کننده ها، لیست تحریم ها، ممیزی.
• Content/Provider Integration Context - ادغام با ارائه دهندگان بازی، کاتالوگ ها، تکنولوژی. وضعیت ها
• تجزیه و تحلیل/مدل های خواندن - پیش بینی ها و نمایشگاه ها برای خواندن محصول.

2) زبان فراگیر: هسته اصلی اصطلاحات

بازیکن، جلسه، GameRound، شرط/بلیط،

ورودی لجر، نگهداری/ذخیره، حل و فصل،

اعتبار پاداش/تعادل پاداش، شرط مورد نیاز (Вейджер)،

KYC ردیف, حد (سپرده/جلسه/از دست دادن), خود حذفی,

ارائه دهنده بازی، پنجره RTP، پرچم خطر، مورد انطباق.

این نام ها به طور مساوی در کد، پایگاه داده، مستندات، تست ها و رابط ها استفاده می شود.

3) Aggregates and invariants (طراحی تاکتیکی)

3. 1 کیف پول (مجموع: «کیف پول»)

• تعادل وارد قلمرو منفی نمی شود.
• رزرو + در دسترس ≤ تعادل کامل.
• سیم کشی اتمی و idemotent (توسط 'operation _ id') است.

• کیف پول. ذخیره (مقدار, دلیل, op_id) → «WalletReserved»
• کیف پول. Commit (op_id) → «WalletCommitted»
• کیف پول. برگشت (op_id) → «برگشت کیف پول»

مرز: کیف پول در مورد شرط/پاداش نمی داند ؛ آن را در خدمت ارسال و رزرو معاملات.

3. 2 شرط/بلیط (مجموع: «شرط»)

• نرخ را می توان تنها در پنجره نقل قول فعال پذیرفت ؛ مقدار ≤ بازیکن/محدودیت جلسه.
• پس از «حل و فصل»، وضعیت «نهایی» است ؛ محاسبه مجدد فقط از طریق عملیات جبران (void/recalc) با حسابرسی واضح مجاز است.

• شرط میبندم. محل (player_id, مقدار, قیمت, op_id) → 'BetPosted' (کیف پول требует. رزرو کنید)
• شرط میبندم. حل و فصل (نتیجه, پرداخت) → 'BetSettled' (نیاز به کیف پول. تعهد/انتشار)
• شرط میبندم. از درجه اعتبار ساقط (دلیل) → 'شرط باطل'

مرز: شرط «صعود» به کیف پول نیست - از طریق دستورات دامنه/ارکستراسیون تماس می گیرد.

3. 3 GameRound (مجموع: «گرد»)

• هر چرخش/دور دارای یک «round _ id» منحصر به فرد و یک مقدار شرط/پیروزی مرتبط است.
• پنجره RTP از آستانه های مشخص شده (در سطح ارائه دهنده + قوانین محلی) تجاوز نمی کند.

• دور زدم. شروع کردم به چرخیدن دور بزن. نتیجه «،» دور. بسته شد.

3. 4 پاداش (مجموع: «BonusGrant»)

• Vager کاهش می یابد تنها از گردش مالی معتبر, پاداش نوشتن آف نمی رفتن به بدهی.
• این امکان وجود ندارد به نوشتن کردن پاداش و بودجه واقعی در همان زمان با توجه به قانون اولویت نیست.

• 'پاداش اعطا'، 'BonusWagered'، 'BonusExpired'، 'BonusConverted'.

4) ارکستراسیون، ساگا و انسجام

همگام (CP): پذیرش شرط و ذخیره وجوه - یک راه: "شرط. محل «→» کیف پول. رزرو '(از طریق تیم دامنه/ارکستر با مهلت).
ناهمزمان (EC): محاسبه نرخ، پاداش تعهدی، تجزیه و تحلیل - از طریق رویدادها + صندوق.
نوع TCC: «TryReserve» (نگه دارید)، «تأیید» (مرتکب)، «لغو» (برگشت) برای اثرات پولی.
Idempotence: تمام دستورات حمل 'operation _ id', consumers - 'inbox'.

5) لایه های ضد فساد (ACLs) و ادغام

ارائه دهنده ACL: ترجمه رویدادهای ارائه دهنده 'SpinResult', 'BonusWin' to internal 'Round. نتیجه "،" شرط پاداش ". طرح ها و نسخه ها در داخل ACL هستند.
PSP ACL: عادی سازی وضعیت پرداخت، بی نظمی توسط «psp _ tx _ id»، انتقال به «LedgerEntry».
ACL: ادغام با لیست های تحریم/RAP - در یک زمینه خارجی ؛ فقط normalized 'ScreeningUpdated' در داخل دامنه دریافت کنید.

قانون: دیکشنری ها/فرمت های خارجی به هسته «نشت» نمی کنند.

6) پیش بینی ها و مدل های خواندن

مدل خوانده شده پروفایل بازیکن: وضعیت KYC، محدودیت ها، پاداش های فعال، معاملات تازه.
تعادل مدل خواندن: خواندن سریع برای UI/بازاریابی ؛ منبع - رویدادهای «کیف پول».
تاریخ شرط خواندن مدل: صفحه بندی بر اساس تاریخ/بازی ؛ منبع «BetPosted/Settled» است.
گزارش های انطباق - دیدگاه های تحقق یافته توسط مستاجر/منطقه.

همه پیش بینی ها upserts idemotent با versioning و «as _ of/freshness» هستند.

7) چند مستاجر و چند منطقه

تمام نهادهای کلیدی حمل «tenant _ id» و (در صورت لزوم) «منطقه».
مرزهای داده: بازیکن، کیف پول، شرط - منطقه «خانه» ؛ فقط گزارش ها/گزارش های بین منطقه ای.
انصاف/سهمیه: محدودیت در تیم/ثانیه و redrives در مستاجران.
اقامت/انطباق: اطلاعات شخصی و معاملات منطقه را ترک نمی کند.

8) انتخاب سازگاری (PACELC) توسط زمینه

کیف پول/لجر - قوی/CP: معاملات خطی، حد نصاب سوابق.
پذیرش شرط - تایید همزمان (CP) + مدل سریع خواندن برای UI.
حل و فصل/پاداش/تجزیه و تحلیل - 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"
}

• طرح های عقب/جلو کامپات ؛ تکامل از طریق «schema _ version».
• در معامله با تغییرات دامنه ؛ انتشار توسط butches با عقب نشینی.

10) به عنوان مثال از «شرط با پاداش» جریان (دنباله کلمه)

1. شرط. Place "(تیم) → بررسی محدودیت بازیکن و → قوانین پاداش کیف پول. رزرو (واقعی + پاداش _ equiv، op_id) '

2. 'BetPosted' → خواندن به روز رسانی مدل 'واگن باز'

3. ارائه دهنده نتایج را → 'ACL دور منتشر می کند. در نتیجه '

4. ارکستر محاسبه می کند: "شرط. حل و فصل (نتیجه، پرداخت) → کیف پول. مرتکب (op_id) 'و, اگر به دست آورد,' BonusWagered '→ تبدیل ممکن است از پاداش به آنهایی که واقعی.
5. 'BetSettled' → پیش بینی تاریخ و ترازنامه، گزارش.

11) سیاست ثابت و آزمایش

• مجموع تمام «LedgerEntry» در کیف پول برابر با تعادل است ؛ باقی مانده منفی نیست.
• شما نمی توانید شرط را با وضعیت KYC فعال/یخ زده بپذیرید.
• شرط بندی تنها می تواند کاهش یابد و نه نوسان «در منهای».
• حل و فصل وضعیت نرخ نهایی شده را تغییر نمی دهد - فقط از طریق «Void/Recalc» + معامله جبران.

• تست های مبتنی بر دارایی از invariants کیف پول و شرط.
• خطوط هرج و مرج: تاخیر ارائه دهنده، شکست PSP، redrives outbox/DLQ.
• کنترل طرح: مهاجرت رویداد، پیش بینی های backfill.

12) تله متری و حسابرسی

معیارهای: p95/p99 در PlaceBet/Reserve/Commit، سهم شکست توسط محدودیت/ACC، نرخ DLQ، موفقیت redrive، پیش بینی تاخیر.
Tracing: spans «komanda → agregat → outbox → konsyumer → proyektsiya», 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)

نسخه در aggregates («نسخه») در برابر به روز رسانی از دست رفته در طول ضبط رقابتی محافظت می کند.

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» برای idempotency هستند، پاسخ ها با «as _ of »/« version» هستند.

15) ایمنی و انطباق

RLS/ACL: تمام درخواست ها - در زمینه «tenant _ id»، دسترسی به نقش.
PII-minimization: جداسازی رویدادهای دامنه از اطلاعات شخصی ؛ پوشش در DLQ/سیاهههای مربوط.
گزارش های نظارتی: پیش بینی هایی با امضای هش بدون تغییر در پنجره های زمان.

16) خطاهای معمول

اتصال قوی بین زمینه (کیف پول می داند شرط/پاداش به طور مستقیم).
نوشتن دوگانه در زمینه های مختلف بدون sagas/outbox → عدم تطابق تعادل و وضعیت.
فقدان فرمان و idempotency مصرف کننده → معاملات تکراری/محاسبات.
جریان قراردادهای ارائه دهنده به مدل دامنه (مهاجرت دشوارتر است).
یک «غول» مجموع (بازیکن شامل همه) قفل →، توان کم است.
هیچ متغیر آشکاری وجود ندارد - آنها نمی توانند بررسی و نظارت شوند.

17) دستور العمل های سریع

شروع: رفع زبان فراگیر و مرزهای زمینه ؛ اسناد ثابت.
پول: کیف پول/لجر - CP، ورودی حد نصاب، TCC برای اثرات خارجی.
شرط ها: دریافت همزمان + محاسبه آسنکرون، همه از طریق رویدادها و صندوق خروجی ؛ توانمندی همه جا هست.
پاداش: واحد جداگانه با روشن نوشتن آف اولویت و vager.
یکپارچگی: همیشه از طریق ACL + طرح/نسخه ؛ هیچ محموله «خام» در هسته وجود ندارد.
خواندن: پیش بینی/نمایش در نیازهای محصول ؛ تازگی SLA + «به عنوان _ از».
عامل: معیارهای ثابت، playbooks DLQ/redrave، بازسازی ویترین.

18) چک لیست پیش فروش

• زمینه های محدود و قراردادهای آنها (دستورات/رویدادها) تعریف شده است.
• aggregates دارای دستورات صریح، نسخه بندی و بی نظیر است.
• معاملات پولی - از طریق TCC/معاملات دقیق ؛ حسابرسی فعال شد
• یکپارچگی - از طریق ACL ها با آزمون های نسخه بندی و تکامل طرح.
• اجرا صندوق خروجی/صندوق ورودی، DLQ و redraw امن است.
• پیش بینی ها تازگی SLA را پیاده سازی می کنند، معیارهای تاخیر/خستگی وجود دارد.
• سهمیه چند مستاجر/محدودیت ها و اقامت داده ها برآورده می شود.
• قابلیت مشاهده: ردیابی «komanda → sobytiye → proyektsiya»، هشدار توسط ناوردا.
• مستندات: زبان دامنه، نمودار زمینه، playbooks حادثه.

نتیجه گیری

DDD در هسته iGaming یک رشته جدایی از پیچیدگی است: مرزهای زمینه روشن، جمع با ناورداها، حوادث به عنوان یک منبع حقیقت، ACLs برای ادغام خارجی، و انتخاب سازگاری آگاهانه. این رویکرد باعث می شود پلت فرم مقیاس پذیر، قابل اعتماد و مطابق با مقررات، سرعت بخشیدن به توسعه ویژگی ها و کاهش خطرات عملیاتی - حتی با رشد سریع ترافیک، جغرافیا و خطوط تولید.