Bounded Context жана чек домен

Bounded Context (BC) - бул бирдиктүү Ubiquitous Language, макулдашылган моделдер жана инварианттар иштеген так чек. Чек аранын ичинде терминдер так ("Коюм", "Кардар", "Лимит"), ал эми контекст контракттар (окуялар/командалар) менен байланышат жана башка бирөөнүн семантикалык "куйруктарын" ичине тартпайт. Туура тандалган чектер байланышты азайтат, масштабдоону жөнөкөйлөтөт жана продуктунун эволюциясын тездетет.

1) Эмне үчүн чек керек

Когнитивдик жүктү азайтуу. Команда "бир эле учурда бүт бизнес" менен эмес, бир модель жана бир тил менен иштейт.
Инварианттарды изоляциялоо. Критикалык эрежелер (балансы ≥ 0, логин уникалдуулугу) бир жерде жашайт жана агрегаттар менен корголгон.
Өзгөрүүлөрдү башкаруу. БКнын ичиндеги схеманын/эрежелердин эволюциясы кошунаны бузбайт - ачык келишимдер бар.
Аткаруу жана ишенимдүүлүк. BC ичинде туура шайкештик моделин жана сактоо тандай аласыз; сыртында - асинхрондук проекциялар.

2) Кантип Bounded Context аныктоо

1. Event Storming: домендик окуяларды "эмне болду" деп жазып, андан кийин "эмне кылууну суранабыз", андан кийин агрегаттар "ким эрежени кепилдейт".

2. Тилдин кластерлери: сөздөр менен эрежелер ырааттуу дал келген жерде - потенциалдуу BC. "Кардар" деген сөз ар башка дегенди билдирет (төлөөчү vs оюнчу) - так ар кандай контексттер бар.

3. Инварианттар жана ownership: эмнени бузууга болбойт жана ким жооп берет? Invariant → аны кепилдик бере алат ошол 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. Коомдук протоколдор/схемалар, чыгаруу жана документтештирилген.

Practice: демейки ACL жана асинхрондук иш-чараларды колдонуу; Conformist - эгерде провайдер стандартты буйруса, Shared Kernel - минималдуу жана аң-сезимдүү.

5) Чек ара = тил + модель + инварианттар + сактоо

• Ubiquitous Language. Терминдердин сөздүгү мисалдар менен.
• Агрегаттар жана инварианттар. Ким эрежелерди "сактайт" жана кандай операцияларга уруксат берилет.
• макулдашуу модели. Strong/CP үчүн акча, EC/causal үчүн терезелер.
• Сактоо жана индекстер. Инварианттар жана SLO үчүн тандалып алынган.
• Чыгуу келишимдери. Events/командалар, схемалар нускалары, SLO жеткирүү.

Сыртта: эч кандай түздөн-түз SQL/таблица көз карандылык. Байланыш - контракт аркылуу.

6) Чек аралар жана шайкештик (PACELC)

BC ичинде: инварианттар үчүн моделди тандоо (Wallet - Strong, Betting - кабыл алуу боюнча Strong).
BC ортосунда: көпчүлүк окуялар жана проекциялар аркылуу eventual. Эгер синхрондуу текшерүү керек болсо - жеткиликсиздик ("жашыруун" REST-чакыруу эмес) мөөнөтү жана баш тартуу менен так команда.

7) Коррупцияга каршы катмар (ACL)

ACL милдети: башка бирөөнүн тилин жана "ыплас" маалыматтарды BC ичине киргизбөө.

Mapping схемалар: тышкы 'PaymentStatus = SETTLED' → ички 'LedgerEntry (type = Credit, reason = PsPSettle)'.
Валидация жана байытуу: инварианттарды текшерүү, таймзондорду, валюталарды нормалдаштыруу.
Версия: колдоо 'schema _ version' тышкы келишим, тескери шайкештик.
Демпотенттик: 'external _ id '/' operation _ id'.
Байкоо: Trace теги '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/чек ара боюнча жогорку жүк (окуя Server/ACL).

11) Чек ара байкоо жана SLO

Метрика: throughput окуялар/команда, 'projection _ lag _ ms', 'dlq _ rate', mapping каталар, p95 API.
Trace: милдеттүү теги 'bc', 'tenant _ id', 'event _ id', 'operation _ id', 'schema _ version'.
Алерталар: проекциялардын ашуусу, командалардын ийгиликсиздигинин өсүшү, "флап" схемасы (көп 'schema _ mismatch').

12) Мультитенант жана региондор

'tenant _ id' - чек арадагы бардык окуялардын жана проекциялардын ачкычында.
Fairness: "ызы-чуу" SLO кошуна сындырып эмес, жарыялоо/Редрайв per tenant боюнча чектер.
Residency: BC маалыматтар "үй" аймагында жашайт; кросс-аймактык - агрегаттар/отчеттор.

13) Анти-үлгүлөрү (бүдөмүк чек алып келет)

Ири "core-service". Баары бир жерде → бүтүмдөр үчүн күрөш, узун релиздер, төмөн автономия.
Таблица интеграциясы. Башка адамдардын жадыбалдарына түздөн-түз SELECT → алсыздык жана схемасы боюнча кууп.
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 картасын жана мамилелердин түрлөрүн тартыңыз.
4. Ичинде жана муундарда шайкештик моделин чечиңиз.
5. Контракттарды (окуялар/командалар) жана ACL долбоорлоо.
6. Пландаштыруу байкоо (метрика/соода/Алерт) жана DLQ/Редрайв.
7. Интеграциялоо үчүн contract-tests жана "бороон" (chaos) өткөрүңүз.
8. governance бекитүү: ким тилди/схеманы билет, өзгөртүүлөр кантип.

16) Азык-түлүктүн алдындагы чек-тизме

• Ар бир БКда сөздүк, агрегаттар жана инварианттар бар.
• Context картасында мамилелер аныкталган жана келишимдер документтештирилген.
• Окуялар/команда жана ACL аркылуу интеграция, эч кандай түздөн-түз SQL көз карандылыгы.
• Командалардын/окуялардын аныктыгы; outbox/inbox жана DLQ бар.
• шайкештик модели (BC ичинде/ортосунда) белгиленген жана сыналган.
• Схемаларды версиялоо жана шайкештик стратегиясы (v1/v2).
• Lag/ката/Performance Metrics жана Алерт орнотулган.
• Көп-тенанттык жана маалымат-residency саясаты сакталат.
• Операциялык плейбуктар: schema-mismatch, redrive, rebuild проекциялары.

17) Тез Recipes

Акча жана лимиттер: CP жана бүтүмдөр менен өзүнчө BC, API гана команда, окуу үчүн чындык натыйжасы катары иш-чаралар.
Фид/каталогдор: EC менен BC, проекциялар жана кэш, ачык 'freshness'.
Тышкы провайдерлер менен интеграция: ар дайым ACL аркылуу, окуялар/командалар, схемаларды версиялоо.
Команданын өсүшү: бир BC - бир команда, команданын "тил ээси" жана "инварианттарды сактоочу" бар.
Монолиттин рефакторинги: биринчи келишимдер жана ACL, андан кийин физикалык бөлүнүү.

Корутунду

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