Bounded Context және домен шектері

Bounded Context (BC) - бұл ішінде бірыңғай Ubiquitous Language, келісілген модельдер мен инварианттар қолданылатын айқын шекара. Шекара iшiнде терминдер бiрдей («Ставка», «Клиент», «Лимит»), ал сыртқа мәтiн келiсiм-шарттармен (оқиғалармен/командалармен) араласады және iшiне бөтен адамдардың мағыналық «қалдықтарын» тартпайды. Сауатты таңдалған шекаралар байланыстылықты төмендетеді, масштабтауды жеңілдетеді және өнімнің эволюциясын жеделдетеді.

1) Шекаралар не үшін қажет

Когнитивтік жүктемені төмендету. Команда «бүкіл бизнеспен бірден» емес, бір модельмен және бір тілмен жұмыс істейді.
Инварианттарды оқшаулау. Сыни ережелер (теңгерім ≥ 0, логиннің бірегейлігі) бір жерде тұрады және агрегаттармен қорғалған.
Өзгертулерді басқару. ВС ішіндегі схема/ережелердің эволюциясы көршіні сындырмайды - айқын келісімшарттар бар.
Өнімділік және сенімділік. BC ішінде үйлесімділік үлгісін және сақтау орнын таңдауға болады; сыртынан - асинхрондық проекциялар.

2) Bounded Context қалай анықталады

1. Event Storming: «не болды» домендік оқиғаларын жазып алыңыз, содан кейін «не істеуіңізді сұраймыз» пәрменін, содан кейін «ережеге кім кепілдік береді» агрегаттарын жазыңыз.

2. Тіл кластерлері: мұнда сөздер мен ережелер тұрақты сәйкес келеді - әлеуетті BC. «Клиент» сөзі әртүрлі (төлеуші vs ойыншы) деген мағынаны білдіретін жерде - контекст анық әртүрлі.

3. Инварианттар және ownership: нені бұзуға болмайды және кім жауап береді? Инвариант → оған кепілдік бере алатын BC ішіне.

4. Құндылықтар ағыны: жиі бірге өзгеретін қадамдарды топтастырыңыз - бұл бір BC кандидаттары.

5. Орг-құрылым: егер бір бөлікті жеке KPI командасы жасаса - бұл жеке BC болуы мүмкін (бірақ керісінше емес: ұйымдастыру құрылымы модельді соқыр нұсқамауы тиіс).

• Терминдер туралы дау («ставка», «билет», «раунд» - әр түрлі мағыналар).
• Ең ыстық инвариант сервистер арқылы өтеді.
• Әртүрлі SLO және өзгеру қарқыны.
• Атомарлық үшін модульдер арасында «Dual-write».

3) Типтік контекстер (пәндік саланың мысалы)

Identity/KYC - тіркеу, верификация деңгейлері, шектеулер мәртебесі.
Wallet/Ledger - баланстар, өткізгіштер, резервтер, валюталар.
Betting/Orders - қабылдау, баға белгілеу, есептеу.
Game/Round - раундтың өмірлік циклі, нәтижелері.
Bonus/Promo - есептеулер, вейджер, конверсия.
Payments - депозиттер/қорытындылар, төлем шлюздерінің мәртебелері.
Compliance/Reporting - есептер, аудит, реттегіш сөрелер.
Catalog/Provider Integration - ойындар, нұсқалар, провайдерлер мәртебесі.
Analytics/Read Models - проекциялар және материалдандырылған көріністер.

4) Context Map: BC қалай өзара іс-қимыл жасайды

• Customer–Supplier. Бір BC (Supplier) оқиғаларды/деректерді жеткізеді, екіншісі (Customer) өз модельдерін реттейді.
• Conformist. Customer Supplier тілін және моделін қалай болса солай қабылдайды (мысалы, нормативтік тізілім).
• Partnership. Екі BC тіл мен келісімшарттар синхронды дамиды (жиі - бір команда/roadmap).
• Shared Kernel. Жалпы ең аз тілдік/кітапхана, бірге нұсқаланады; абайлап пайдалану керек.
• Anti-Corruption Layer (ACL). Бөтен үлгілерді өз тіліне аударатын қорғау қабаты.
• Open Host Service / Published Language. Нұсқаланатын және құжатталған жария хаттамалар/схемалар.

Тәжірибе: әдепкі ACL және асинхронды оқиғаларды пайдаланыңыз; Conformist - егер провайдер стандартты талап етсе, Shared Kernel - минималды және саналы түрде.

5) Шекара = тіл + модель + инварианттар + сақтау орны

• Ubiquitous Language. Мысалдары бар терминдер сөздігі.
• Агрегаттар мен инварианттар. Ережелерді кім «ұстайды» және қандай операцияларға рұқсат етіледі.
• Үйлесімділік моделі. Ақшаға арналған Strong/CP, витриналарға арналған EC/causal.
• Сақтау орны және индекстер. Инварианттарға және SLO-ға таңдалады.
• Шығу келісімшарттары. Оқиғалар/командалар, схемалар нұсқалары, жеткізу СЛО.

Сыртқы: тікелей SQL/кесте тәуелділіктері жоқ. Қарым-қатынас - келісімшарт арқылы.

6) Шекаралар және келісу (PACELC)

BC ішінде: инварианттар үшін үлгіні таңдаңыз (Wallet - Strong, Betting - қабылдауда Strong).
BC арасында: көбінесе оқиғалар мен проекциялар арқылы eventual. Егер синхронды тексеру қажет болса - қол жеткізбеушілік кезінде мерзімі ұзартылған және істен шыққан анық пәрмен («жасырын» REST шақыру емес).

7) Сыбайлас жемқорлыққа қарсы қабат (ACL)

ACL міндеті: бөтен тілді және «лас» деректерді BC ішіне енгізбеу.

Схемалардың маппингі: сыртқы 'PaymentStatus = SETTLED' → ішкі 'LedgerEntry (type = Credit, reason = PsPSettle)'.
Валидация және байыту: инварианттарды тексеру, таймзондарды, валюталарды қалыпқа келтіру.
Нұсқалау: сыртқы келісімшартты 'schema _ version' қолдау, кері үйлесімділік.
Сәйкестік: 'external _ id '/' operation _ id' бойынша.
Бақылануы: «улы» хабарлар үшін 'source', 'schema _ version', 'mapping _ id', DLQ трес-тегтері.

8) Шекаралар және деректер: иелену, проекция, API

Ownership: «шындыққа» кім ие? Тек иесі жазбаны өзгертеді. Қалған BC - оқу модельдері мен сілтемелер.
Проекциялар: оқылуға арналған нормаланған кестелер; оқиғалардан жаңартылады.
API: командалар (иесінен мутацияланады) және сұраулар (проекцияларды оқиды). Басқа адамдардың деректерінің «өтпелі» жаңартулары жоқ.

9) Эволюция және нұсқалар

Оқиғалар мен API - 'schema _ version' және сыйысымдылық саясатымен (additive + fallback).
BC бойынша Blue/Green: жаңа келісімшарт 'v2' қатар 'v1' жарияланады, трафик біртіндеп аударылады.
Көші-қон: маңызды өзгерістер үшін - жаңа проекция/сервис, оқулықтардың «екі фазалы свитч».

10) Шекараларды тестілеу

Contract tests: BC жарияланған келісімшартты (producer tests) сақтайтынын және басқаның (consumer tests) дұрыс түсінетінін тексеру.
Property-based: BC ішіндегі агрегаттардың инварианттары (теңгерім, лимиттер, бірегейліктер).
Интеграциялардағы Chaos: кідірістер, out-of-order, телнұсқалар, schema-evolution; DLQ және қауіпсіз редрайвтың болуы.
NFR-тесттер: p95/шекарадағы ең жоғары жүктеме (оқиғалар сервері/ACL).

11) Шекаралар бойынша бақылау және SLO

Оқиғалар/командалар өлшемдері: throughput, 'projection _ lag _ ms', 'dlq _ rate', маппинг қателері, p95 API.
Трейсинг: міндетті тегтер 'bc', 'tenant _ id', 'event _ id', 'operation _ id', 'schema _ version'.
Алерттар: проекция ағынының артуы, команда істен шығуының өсуі, «флап» схемасы (көп 'schema _ mismatch').

12) Мульти-тенант және өңірлер

'tenant _ id' - шекарадағы барлық оқиғалар мен проекциялардың кілттерінде.
Fairness: «шулы» көршілердің SLO-сын бұзбау үшін жарияланымдар/редрайв per tenant лимиттері.
Residency: BC деректері «үй» аймағында тұрады; кросс-өңірлік - агрегаттар/есептер.

13) Анти-паттерндер (бұлдыр шекара неге әкеледі)

Алпауыт «core-service». Барлығы бір жерде → транзакциялар үшін күрес, ұзын релиздер, төмен дербестік.
Кестелік интеграциялар. Басқалардың кестелеріне ТІКЕЛЕЙ SELECT → сұлба бойынша морт және coupling.
Dual-write. Бір уақытта екі BC жазу «ыңғайлы болу үшін» → айырмашылықтар және инварианттар саботажы.
Әдепкі Conformist. «Басқаның моделін қабылдадық» → басқаның мағынасының шығып кетуі, эволюцияның мүмкін еместігі.
Жасырын синхронды қоңыраулар. 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. Context Map және қатынас түрлерін сызыңыз.
4. Ішкі және жапсарлас үйлесімділік моделін шешіңіз.
5. Келісімшарттарды (оқиғалар/командалар) және ACL жобалаңыз.
6. Байқауды (метрика/трейсинг/алерта) және DLQ/редрайв жоспарлаңыз.
7. Интеграциялар үшін contract-tests және «дауыл» (chaos) жүргізіңіз.
8. governance бағдарламасын белгілеңіз: тілді/схеманы кім біледі, өзгерістер қалай енгізіледі.

16) Азық-түлік алдындағы чек-парағы

• Әрбір BC-де сөздік, агрегаттар және инварианттар бар.
• Context Map-та қатынастар анықталды және келісімшарттар құжатталды.
• Оқиғалар/командалар және ACL арқылы интеграциялау, тікелей SQL тәуелділігі жоқ.
• Командалардың/оқиғалардың ұқсастығы; outbox/inbox және DLQ бар.
• Келісу моделі (БС ішінде/арасында) тіркелген және сыналған.
• Схемаларды нұсқалау және үйлесімділік стратегиясы (v1/v2).
• Лаг/қателер/өнімділік өлшемдері мен тәуекелдер теңшелген.
• Мульти-тенанттық және data-residency саясаты сақталған.
• Операциялық плейбуктар: schema-mismatch, redrive, rebuild проекциялары.

17) Жылдам рецепттер

Ақша мен лимиттер: CP және транзакциялары бар жеке BC, тек командалар үшін API, оқылым үшін ақиқаттың нәтижесі ретінде оқиғалар.
Фидтер/каталогтар: EC бар BC, проекциялар мен кэш, анық 'freshness'.
Сыртқы провайдерлермен интеграциялау: әрқашан ACL, оқиғалар/командалар, схемаларды нұсқалау арқылы.
Команданың биіктігі: бір BC - бір команда, командада «тіл иесі» және «инварианттарды сақтаушы» бар.
Монолитті рефакторинг: алдымен келісімшарттар мен ACL, содан кейін физикалық бөліну.

Қорытынды

Bounded Context - бұл тек диаграмма ғана емес, тіл, ережелер және эволюция тәсілі туралы жұмыс шарты. Нақты шекаралар байланыстылықты азайтады, өзгерістерді жылдамдатады және жүйені пайдалануды болжауға болады. Мәндеріне және инварианттарына қарай бөліңіз, ACL шектерін және келісімшарттарды қорғаңыз, барлық өлшемдерді өлшеңіз - домен мен пәрмен тез өскен кезде де архитектураңыз икемді және сенімді болып қалады.