زمینه محدود و مرزهای دامنه

زمینه محدود (BC) یک مرز واضح است که در آن یک زبان همه جا حاضر، مدل های سازگار و ناوردا عمل می کنند. در داخل مرز، اصطلاحات بدون ابهام هستند («Bet»، «Client»، «Limit»)، و در خارج از متن با قراردادها (رویدادها/تیم ها) ارتباط برقرار می کند و در دم های معنایی افراد دیگر نمی کشد. مرزهای هوشمندانه انتخاب شده باعث کاهش اتصال، ساده سازی مقیاس بندی و سرعت بخشیدن به تکامل محصول می شود.

1) چرا به مرزها نیاز داریم ؟

کاهش بار شناختی. این تیم با یک مدل و یک زبان کار می کند، نه «کل کسب و کار در یک بار».
جدا کردن ناورداها قوانین بحرانی (تعادل ≥ 0، ورود به سیستم منحصر به فرد) در یک مکان زندگی می کنند و توسط aggregates محافظت می شود.
مدیریت تغییر تکامل طرح/قوانین در BC همسایه را شکست نمی دهد - قراردادهای صریح وجود دارد.
عملکرد و قابلیت اطمینان. در یک BC، یک مدل سازگاری مناسب و ذخیره سازی می تواند انتخاب شود ؛ خارج - پیش بینی های ناهمزمان.

2) چگونگی شناسایی زمینه محدود

1. Event Storming: رویدادهای دامنه «آنچه اتفاق افتاده است» را بنویسید، سپس دستورات «چه کاری می خواهید انجام دهید»، سپس aggregates «چه کسی قانون را تضمین می کند».

2. خوشه های زبان: جایی که کلمات و قوانین به طور مداوم مطابقت دارند - BC بالقوه. جایی که کلمه «مشتری» به معنای متفاوت است (پرداخت کننده در مقابل بازیکن) - زمینه های مختلفی وجود دارد.

3. متغیر و مالکیت: چه چیزی نمی تواند نقض شود و چه کسی مسئول است ؟ ناوردا → در داخل BC که می تواند آن را تضمین کند.

4. جریان ارزش: مراحل گروهی که اغلب با هم تغییر می کنند - این نامزدها برای یک BC هستند.

5. ساختار سازمانی: اگر یک بخش توسط یک تیم جداگانه با KPI های جداگانه ساخته شده باشد، این احتمالا یک BC جداگانه است (اما نه برعکس: ساختار سازمانی نباید کورکورانه مدل را دیکته کند).

• اختلاف در مورد اصطلاحات («شرط»، «بلیط»، «دور» - معانی مختلف).
• داغترین «جریان» ناوردا از طریق خدمات.
• SLO های مختلف و سرعت تغییر.
• «نوشتن دوگانه» بین ماژول ها به خاطر اتمی بودن.

3) زمینه های معمول (مثال دامنه)

هویت/KYC - ثبت نام، سطح تأیید، وضعیت محدودیت.
کیف پول/لجر - تعادل، معاملات، ذخایر، ارزها.
شرط بندی/سفارشات - پذیرش, نقل قول, محاسبه.
بازی/دور - چرخه زندگی دور، نتایج.
پاداش/تبلیغاتی - تعهدات، vager، تبدیل.
پرداخت ها - سپرده ها/برداشت ها، وضعیت های دروازه پرداخت.
انطباق/گزارش - گزارش ها، ممیزی ها، ویترین های نظارتی.
کاتالوگ/ارائه دهنده ادغام - بازی ها، نسخه ها، وضعیت ارائه دهندگان.
تجزیه و تحلیل/مدل های خواندن - پیش بینی ها و دیدگاه های تحقق یافته.

4) نقشه زمینه: چگونه BCs تعامل

• مشتری عرضه کننده. یکی BC (تامین کننده) رویدادها/داده ها را ارائه می دهد، دیگری (مشتری) مدل های خود را تنظیم می کند.
• سازگار است. مشتری زبان و مدل تامین کننده را می پذیرد (به عنوان مثال دفتر ثبت مقررات).
• شراکت. دو BC به طور همزمان زبان و قراردادها را تکامل می دهند (اغلب یک دستور/نقشه راه).
• هسته مشترک مشترک حداقل زبان فرعی/کتابخانه، نسخه به طور مشترک ؛ با دقت استفاده کنید.
• لایه ضد فساد (ACL) یک لایه محافظ که مدل های دیگر افراد را به زبان خود ترجمه می کند.
• باز کردن سرویس میزبان/زبان منتشر شده. پروتکل ها/طرح های عمومی، نسخه و مستند.

تمرین: استفاده از ACL ها و رویدادهای آسنکرون به طور پیش فرض ؛ مطابقت - فقط اگر ارائه دهنده استاندارد، هسته مشترک را به حداقل و آگاهانه تحمیل کند.

5) محدود = زبان + مدل + ثابت + ذخیره سازی

• زبان فراگیر. دیکشنری اصطلاحات همراه با مثال
• ترکیب ها و تغییرناپذیر ها چه کسی «قوانین» را نگه می دارد و چه عملیات مجاز است.
• مدل سازگاری قوی/CP برای پول، EC/علیت برای ویترین.
• ذخیره سازی و شاخص ها. انتخاب شده برای متغیر و SLO.
• قراردادهای خروج رویدادها/دستورات، نسخه های طرح، SLO تحویل.

خارج: هیچ وابستگی مستقیم SQL/table وجود ندارد. ارتباط - از طریق یک قرارداد.

6) مرزها و سازگاری (PACELC)

در داخل BC: یک مدل برای invariants (کیف پول - قوی، شرط بندی - قوی در پذیرش) را انتخاب کنید.
بین BC: اغلب از طریق رویدادها و پیش بینی ها. اگر تأیید همزمان مورد نیاز است، یک دستور صریح با مهلت و شکست زمانی که در دسترس نیست (نه یک تماس «پنهان» REST).

7) لایه ضد فساد (ACL)

وظیفه ACL این است که اجازه ندهید زبان شخص دیگری و داده های کثیف در داخل BC.

نگاشت طرحواره: external 'PaymentStatus = SETTED' → internal 'LedgerEntry (نوع = اعتبار، دلیل = PsPSettle)'.
اعتبار سنجی و غنی سازی: تأیید ناورداها، عادی سازی زمان، ارزها.
نسخه: پشتیبانی از قرارداد خارجی «schema _ version»، سازگاری عقب مانده.
Idempotence: توسط 'external _ id '/' operation _ id'.
قابلیت مشاهده: برچسب های ردیابی 'source'، 'schema _ version'، 'mapping _ id'، DLQ برای پیام های سمی.

8) مرزها و داده ها: مالکیت، پیش بینی ها، API

مالکیت: چه کسی صاحب «حقیقت» است ؟ تنها مالک میتواند رکورد را تغییر دهد. بقیه BC - خواندن مدل ها و لینک ها.
پیش بینی ها: جداول غیر طبیعی برای خواندن ؛ از حوادث به روز می شوند.
API: دستورات (جهش در مالک) و درخواست ها (خواندن پیش بینی ها). هیچ «پایان به پایان» به روز رسانی از داده های افراد دیگر.

9) تکامل و نسخه

رویدادها و API ها - با «schema _ version» و سیاست سازگاری (افزودنی + بازپرداخت).
آبی/سبز توسط BC: قرارداد جدید «v2» به موازات «v1» منتشر می شود، ترافیک به تدریج منتقل می شود.
مهاجرت: برای تغییرات عمده - یک طرح/سرویس جدید، یک «سوئیچ دو فاز» خواندن.

10) تست مرزی

تست های قرارداد: بررسی اینکه BC مطابق با قرارداد منتشر شده (تست های تولید کننده) و به درستی درک شخص دیگری (تست های مصرف کننده) است.
املاک مبتنی بر: ثابت از مصالح در BC (تعادل، محدودیت، منحصر به فرد).
هرج و مرج در ادغام: تاخیر، خارج از نظم، تکراری، طرح تکامل ؛ حضور DLQ و redrave امن.
تست NFR: p95/بار پیک در مرز (سرور رویداد/ACL).

11) قابل مشاهده و SLO توسط مرز

متریک: توان رویدادها/دستورات، 'projection _ lag _ ms'، 'dlq _ rate'، خطاهای نقشه برداری، API p95.
ردیابی: برچسب های اجباری «bc»، «tenant _ id»، «event _ id»، «operation _ id»، «schema _ version».
هشدارها: بیش از تاخیر طرح ریزی، افزایش شکست فرمان، طرح «فلپ» (بسیاری از «طرح _ عدم تطابق»).

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

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

13) ضد الگوهای (و در نتیجه مرز تار)

غول "هسته خدمات. "همه چیز در یک مکان - مبارزه برای معاملات، انتشار طولانی، استقلال کم.
ادغام جدول. خطوط SELECT به جداول خارجی → شکنندگی و اتصال با توجه به طرح.
نوشتن دوگانه در همان زمان، نوشتن در دو BCs «برای راحتی» → اختلافات و خرابکاری ناوردایی.
مطابق با پیش فرض. «مدل شخص دیگری را همانطور که هست پذیرفت» - نشت معانی دیگران، عدم امکان تکامل.
تماسهای مخفی همزمان تماس REST «جایی در داخل» بدون قرارداد صریح و مهلت → وابستگی غیر منتظره به در دسترس بودن.

14) نمونه ای از خطوط (طرح کلامی)

[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->

[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]

15) مینی راهنمای انتخاب مرز

1. فرمول ثابت و تعیین که می تواند آنها را تضمین کند.
2. فرهنگ لغت (10-20 اصطلاح) را توصیف کنید و مطمئن شوید که تیم همان درک را دارد.
3. نقشه زمینه و انواع روابط را ترسیم کنید.
4. حل مدل سازگاری در داخل و در مفاصل.
5. قراردادهای طراحی (رویدادها/دستورات) و ACL ها.
6. برنامه ریزی برای قابلیت مشاهده (متریک/ردیابی/هشدار) و DLQ/redrive.
7. اجرای تست قرارداد و هرج و مرج برای ادغام.
8. مدیریت ثابت: چه کسی صاحب زبان/طرح است، چگونه تغییرات ایجاد می شود.

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

• هر BC دارای واژگان، aggregates و invariants است.
• روابط در نقشه زمینه تعریف شده و قراردادها مستند شده اند.
• ادغام از طریق رویدادها/دستورات و ACL ها، هیچ وابستگی مستقیم SQL.
• توانایی فرماندهی/رویداد ؛ صندوق ورودی/صندوق ورودی و DLQ وجود دارد.
• مدل سازگاری (درون/بین BC) ثابت و آزمایش شده است.
• نسخه بندی طرح و استراتژی سازگاری (v1/v2).
• تاخیر/خطا/معیارهای عملکرد و هشدارها پیکربندی شده است.
• سیاست های چند اجاره ای و اقامت داده ها اعمال می شود.
• playbooks عامل: طرح عدم تطابق، redrive، بازسازی پیش بینی.

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

پول و محدودیت ها: BC جداگانه با CP و معاملات، API تنها دستورات، حوادث به عنوان نتیجه حقیقت برای خواندن.
خوردها/دایرکتوری ها: BC با EC، پیش بینی ها و کش، صریح «طراوت».
یکپارچگی با ارائه دهندگان خارجی: همیشه از طریق ACL ها، رویدادها/دستورات، نسخه بندی طرح.
رشد تیم: یک BC یک تیم است، تیم دارای «صاحب زبان» و «دروازه بان ناوردا» است.
بازسازی یکپارچه: ابتدا قراردادها و ACL ها، سپس جدایی فیزیکی.

نتیجه گیری

متن محدود نه تنها یک نمودار است، بلکه یک توافق کاری در مورد زبان، قوانین و راه تکامل است. مرزهای روشن باعث کاهش اتصال، تغییر سرعت و ایجاد سیستم قابل پیش بینی برای کار می شود. جدا از معنا و ناوردا، از مرزها و قراردادهای ACL محافظت کنید، همه چیز را با معیارها اندازه گیری کنید - و معماری شما حتی با رشد سریع دامنه و تیم انعطاف پذیر و قابل اعتماد خواهد بود.