Bounded Context va domen chegaralari

Bounded Context (BC) - bu yagona Ubiquitous Language, kelishilgan modellar va invariantlar amal qiladigan aniq chegara. Chegara ichida atamalar bir ma’noda («Stavka», «Mijoz», «Limit»), kontekst esa kontraktlar (voqealar/jamoalar) bilan aloqa qiladi va boshqalarning mazmunli «dumlarini» ichkariga tortmaydi. Toʻgʻri tanlangan chegaralar bogʻlanishni kamaytiradi, kattalashtirishni soddalashtiradi va mahsulot evolyutsiyasini tezlashtiradi.

1) Chegaralar nima uchun kerak?

Kognitiv yuklamani kamaytirish. Jamoa «bir vaqtning o’zida butun biznes» bilan emas, balki bitta model va bitta til bilan ishlaydi.
Invariantlarni izolyatsiya qilish. Tanqidiy qoidalar (0 ≥ balans, loginning o’ziga xosligi) bir joyda yashaydi va agregatlar bilan himoyalangan.
Oʻzgarishlarni boshqarish. BC ichidagi sxema/qoidalarning evolyutsiyasi qo’shnini buzmaydi - aniq shartnomalar mavjud.
Unumdorlik va ishonchlilik. BC ichida mos kelishuv modeli va omborni tanlash mumkin; tashqi tomondan - asinxron proyeksiyalar.

2) Bounded Context ni qanday aniqlash mumkin

1. Event Storming: domen voqealarini «nima bo’ldi», so’ngra «nima qilishni so’raymiz» buyruqlarini, so’ngra «qoidani kim kafolatlaydi» agregatlarini yozing.

2. Til klasterlari: so’zlar va qoidalar bir-biriga mos keladigan joyda - potentsial BC. «Mijoz» so’zi har xil (to’lovchi va o’yinchi) degan ma’noni anglatsa, kontekstlar aniq farq qiladi.

3. Invariantlar va ownership: nimani buzish mumkin emas va kim javob beradi? Invariant → uni kafolatlaydigan BC ichida.

4. Qiymat oqimi: ko’pincha birgalikda o’zgaradigan qadamlarni guruhlang - bu bitta BC uchun nomzodlar.

5. Org-tuzilma: agar bitta qism alohida KPI bilan alohida buyruq bilan bajarilsa, ehtimol bu alohida BC (lekin aksincha emas: tashkiliy tuzilma modelni ko’r-ko’rona buyurmasligi kerak).

• Atamalar to’g "risidagi bahslar (" stavka "," chipta "," raund "- turli ma’nolar).
• Eng issiq invarant xizmatlar orqali «oqadi».
• Turli SLO va o’zgarish sur’ati.
• «Dual-write» modullar o’rtasida.

3) Tipik kontekstlar (fan sohasiga misol)

Identity/KYC - ro’yxatdan o’tish, verifikatsiya darajalari, cheklovlar maqomi.
Wallet/Ledger - balanslar, simlar, zaxiralar, valyutalar.
Betting/Orders - qabul qilish, kotirovka qilish, hisob-kitob qilish.
Game/Round - raundning hayot sikli, natijalar.
Bonus/Promo - hisoblashlar, veyjer, konvertatsiya.
Payments - depozitlar/xulosalar, to’lov shlyuzlarining maqomlari.
Compliance/Reporting - hisobotlar, audit, tartibga soluvchi vitrinalar.
Catalog/Provider Integration - o’yinlar, versiyalar, provayderlar maqomi.
Analytics/Read Models - proyeksiyalar va materiallashtirilgan tasavvurlar.

4) Context Map: BC qanday hamkorlik qiladi

• Customer–Supplier. Bitta BC (Supplier) hodisalarni/maʼlumotlarni yetkazib beradi, ikkinchisi (Customer) esa oʻz modellarini moslashtiradi.
• Conformist. Customer mavjud til va Supplier modelini qabul qiladi (masalan, normativ reyestr).
• Partnership. Ikkita BC til va shartnomalarni sinxron ravishda rivojlantiradi (ko’pincha bitta jamoa/roadmap).
• Shared Kernel. Umumiy minimal kichik til/kutubxona birgalikda versiya qilinadi; ehtiyotkorlik bilan foydalanish.
• Anti-Corruption Layer (ACL). Boshqa odamlarning modellarini o’z tiliga o’tkazadigan himoya qatlami.
• Open Host Service / Published Language. Ommaviy bayonnomalar/sxemalar, versiyalashtiriladigan va hujjatlashtirilgan.

Amaliyot: andoza ravishda ACL va asinxron hodisalardan foydalaning; Conformist - agar provayder standartni talab qilsa, Shared Kernel - minimal va ongli ravishda.

5) Chegara = til + model + invariantlar + ombor

• Ubiquitous Language. Misollar bilan atamalar lugʻati.
• Agregatlar va invariantlar. Qoidalarni kim «ushlab turadi» va qanday operatsiyalarga ruxsat berilgan.
• Muvofiqlik modeli. Strong/CP pul uchun, EC/causal vitrinalar uchun.
• Ombor va indekslar. Invariantlar va SLO uchun tanlanadi.
• Chiqish kontraktlari. Hodisalar/buyruqlar, sxemalar versiyasi, yetkazib berish SLO.

Tashqi tomondan: to’g’ridan-to’g’ri SQL/jadvalga bog’liqlik yo’q. Aloqa - kontrakt orqali.

6) Chegaralar va muvofiqlik (PACELC)

BC ichida: invariantlar uchun modelni tanlang (qabulda Wallet - Strong, Betting - Strong).
BC o’rtasida: ko’pincha voqealar va proyeksiyalar orqali eventual. Sinxron tekshirish kerak boʻlganda - muddati tugagan va yetib boʻlmaganda rad etilgan aniq buyruq («yashirin» REST chaqiruvi emas).

7) Korrupsiyaga qarshi kurash qatlami (ACL)

ACL vazifasi: birovning tilini va «iflos» maʼlumotlarni BC ichiga kiritmaslik.

Mapping sxemalari: tashqi’PaymentStatus = SETTLED’→ ichki’LedgerEntry (type = Credit, reason = PsPSettle)’.
Validatsiya va boyitish: invariantlarni tekshirish, taymzonlar, valyutalarni normallashtirish.
Versionlash: tashqi shartnomaning «schema _ version» ni qoʻllab-quvvatlash, teskari muvofiqlik.
Idempotentlik:’external _ id ’/’ operation _ id’.
Kuzatilganlik: «zaharli» xabarlar uchun’source’,’schema _ version’,’mapping _ id’, DLQ treys-teglari.

8) Chegaralar va ma’lumotlar: egalik qilish, proyeksiyalar, API

Ownership: «haqiqat» kimga tegishli? Faqat egasi yozuvni oʻzgartiradi. Qolgan BC - o’qish modellari va havolalari.
Proyeksiyalar: o’qish uchun denormallashtirilgan jadvallar; hodisalardan yangilanadi.
API: buyruqlar (egasida mutatsiyalar) va soʻrovlar (proyeksiyalarni oʻqish). Boshqa odamlarning ma’lumotlarining «o’tish» yangiliklari yo’q.

9) Evolyutsiya va versiyalar

Voqealar va API -’schema _ version’va muvofiqlik siyosati (additive + fallback).
Blue/Green by BC: yangi kontrakt’v2’ga parallel ravishda’v1’e’lon qilinadi, trafik bosqichma-bosqich o’tkaziladi.
Migratsiya: jiddiy o’zgarishlar uchun - yangi proyeksiya/xizmat, «ikki fazali svitch» o’qish.

10) Chegaralarni sinovdan o’tkazish

Contract tests: BC e’lon qilingan shartnomaga (producer tests) rioya qilishini va boshqa birovning (consumer tests) to’g’ri tushunishini tekshirish.
Property-based: BC ichidagi agregatlarning invariantlari (balans, limitlar, noyobliklar).
Integratsiyalarda Chaos: kechikishlar, out-of-order, dublikatlar, schema-evolution; DLQ va xavfsiz redrayvning mavjudligi.
NFR testlari: p95/chegaradagi eng yuqori yuk (hodisa serveri/ACL).

11) Chegaralar bo’yicha kuzatish va SLO

Hodisalar/buyruqlar metrikasi:’projection _ lag _ ms’,’dlq _ rate’, mapping xatolari, p95 API.
Treysing: majburiy teglar’bc’,’tenant _ id’,’event _ id’,’operation _ id’,’schema _ version’.
Alertlar: ko’p’schema _ mismatch’(ko’p’schema _ mismatch’).

12) Multi-tenant va hududlar

’tenant _ id’ - chegaradagi barcha voqealar va proyeksiyalar kalitida.
Fairness: «shovqinli» qo’shnilarning SLOsini buzmasligi uchun nashr/tahrir cheklovlari.
Residency: BC ma’lumotlari «uy» hududida yashaydi; kross-mintaqaviy - agregatlar/hisobotlar.

13) Anti-patternlar (noaniq chegara nimaga olib keladi)

Ulkan «core-service». Hammasi bir joyda → tranzaksiyalar uchun kurash, uzoq relizlar, past avtonomiya.
Jadval integratsiyalari. To’g’ridan-to’g’ri SELECT to’g’ridan-to’g’ri o’zgalar jadvaliga → zaiflik va sxema bo’yicha coupling.
Dual-write. Bir vaqtning o’zida ikkita BCga «qulaylik uchun» yozish → farqlar va invariantlarni sabotaj qilish.
Andoza conformist. «Birovning modelini xuddi shunday qabul qildik» → birovning ma’nosining chiqib ketishi, evolyutsiyaning mumkin emasligi.
Yashirin sinxron qoʻngʻiroqlar. REST-qo’ng’iroq «ichkarida» aniq kontrakt va muddatsiz → foydalanish imkoniyati bo’yicha kutilmagan bog’liqlik.

14) Konturlar namunasi (so’z sxemasi)

[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) Chegara tanlash bo’yicha mini-gidlar

1. Invariantlarni shakllantiring va ularni kim kafolatlashi mumkinligini aniqlang.
2. Lugʻatni taʼriflab bering (10-20 ta atama) va jamoada bir xil tushuncha borligiga ishonch hosil qiling.
3. Context Map va munosabatlar turlarini chizing.
4. Uyg’unlik modelini ichki va bo’g’inlarda hal qiling.
5. Shartnomalar (voqealar/buyruqlar) va ACLni loyihalashtiring.
6. Kuzatishni (metriklar/treysing/alert) va DLQ/redrayvni rejalashtiring.
7. Integratsiya uchun contract-tests va «boʻron» (chaos) ni oʻtkazing.
8. Governance: Til/sxemani kim biladi, oʻzgarishlar qanday kiritiladi.

16) Sotishdan oldingi chek-varaq

• Har bir BCda lugʻat, agregatlar va invariantlar mavjud.
• Context Map’dagi munosabatlar aniqlandi va shartnomalar hujjatlashtirildi.
• Voqealar/buyruqlar va ACL orqali integratsiya, to’g’ridan-to’g’ri SQL bog’liqliklari yo’q.
• Jamoalar/hodisalarning idempotentligi; outbox/inbox va DLQ mavjud.
• Muvofiqlik modeli (BC ichida/o’rtasida) o’rnatildi va sinovdan o’tkazildi.
• Sxemalarni versiyalash va muvofiqlik strategiyasi (v1/v2).
• Lag/xato/unumdorlik metrikasi va alertlar sozlangan.
• Ko’p tenantlik va data-residency siyosatiga rioya qilingan.
• Operatsion pleybuklar: schema-mismatch, redrive, rebuild proyeksiyalari.

17) Tezkor retseptlar

Pul va limitlar: CP va tranzaksiyalar bilan alohida BC, faqat buyruqlar bilan API, o’qish uchun haqiqat natijasi sifatida voqealar.
Fayllar/kataloglar: EC bilan BC, projeksiyalar va kesh, aniq’freshness’.
Tashqi provayderlar bilan integratsiyalash: har doim ACL, voqealar/buyruqlar, sxemalarni versiyalash orqali.
Jamoaning o’sishi: bitta BC - bitta jamoa, jamoada «til egasi» va «invariant saqlovchi» mavjud.
Monolitning refaktoringi: avval shartnomalar va ACL, so’ngra jismoniy bo’linish.

Xulosa

Bounded Context - bu nafaqat diagramma, balki til, qoidalar va evolyutsiya usuli to’g’risidagi ish shartnomasi. Aniq chegaralar bog’liqlikni kamaytiradi, o’zgarishlarni tezlashtiradi va tizimni oldindan aytib bo’lmaydigan qiladi. Ma’no va o’zgarishlarga qarab bo’ling, ACL va shartnomalar chegaralarini himoya qiling, hamma narsani metrik o’lchang - va hatto domen va buyruq tez o’sganda ham arxitekturangiz moslashuvchan va ishonchli bo’lib qoladi.