Bounded Context və domen sərhədləri

Bounded Context (BC) vahid Ubiquitous Language, razılaşdırılmış modellər və invariantların fəaliyyət göstərdiyi aydın sərhəddir. Sərhədin daxilində terminlər birmənalıdır («Mərc», «Müştəri», «Limit»), kontekst isə müqavilələrlə (hadisələrlə/komandalarla) ünsiyyət qurur və başqalarının semantik «quyruqlarını» içəriyə çəkmir. Düzgün seçilmiş sərhədlər əlaqəni azaldır, miqyası asanlaşdırır və məhsulun təkamülünü sürətləndirir.

1) Niyə sərhədlər lazımdır

Bilişsel yükün azaldılması. Komanda 'bir anda bütün biznes "deyil, bir model və bir dil ilə işləyir.
İnvariantların izolyasiyası. Kritik qaydalar (balans ≥ 0, login unikallığı) bir yerdə yaşayır və aqreqatlarla qorunur.
Dəyişikliklərin idarə edilməsi. BC daxilində sxem/qaydaların təkamülü qonşunu qırmır - aydın müqavilələr var.
Performans və etibarlılıq. BC daxilində uyğun uyğunluq və saxlama modelini seçə bilərsiniz; xaricində - asinxron proyeksiyalar.

2) Bounded Context necə müəyyənləşdirilir

1. Event Storming: «Nə oldu» domen hadisələrini, sonra «xahiş edirik» əmrini, sonra «qaydaya kim zəmanət verir» aqreqatlarını yazın.

2. Dil klasterləri: sözlərin və qaydaların sabit şəkildə üst-üstə düşdüyü yerlərdə - potensial BC. Harada «müştəri» sözü fərqli deməkdir (ödəyici vs oyunçu) - aydın fərqli kontekstlər var.

3. İnvariantlar və ownership: nə pozula bilməz və kim cavab verir? Invariant → onu təmin edə bilər BC daxilində.

4. Dəyər axını: tez-tez birlikdə dəyişən addımları qruplaşdırın - bunlar bir BC üçün namizədlərdir.

5. Org-struktur: bir hissə ayrı KPI ilə ayrı bir komanda edirsə - yəqin ki, ayrı bir BC (lakin əksinə deyil: təşkilat strukturu kor-koranə model diktə etməməlidir).

• Terminlər haqqında mübahisə («bahis», «bilet», «tur» - müxtəlif mənalar).
• Ən isti invarant xidmətlər vasitəsilə «axır».
• Müxtəlif SLO və dəyişmə sürəti.
• Atom gücünə görə modullar arasında «Dual-write».

3) Tipik kontekstlər (mövzu sahəsi nümunəsi)

Identity/KYC - qeydiyyat, yoxlama səviyyələri, məhdudiyyətlərin statusu.
Wallet/Ledger - balanslar, naqillər, ehtiyatlar, valyutalar.
Betting/Orders - qəbul, kotirovka, hesablama.
Game/Round - raundun həyat dövrü, nəticələr.
Bonus/Promo - hesablamalar, veycer, konvertasiya.
Payments - depozitlər/rüsumlar, ödəniş şlüzlərinin statusları.
Compliance/Reporting - hesabatlar, audit, tənzimləyici vitrinlər.
Catalog/Provider Integration - oyunlar, versiyalar, provayder statusları.
Analytics/Read Models - proyeksiyalar və materiallaşdırılmış təsəvvürlər.

4) Context Map: BC necə qarşılıqlı

• Customer–Supplier. Bir BC (Supplier) hadisələri/məlumatları təmin edir, digəri (Customer) öz modellərini uyğunlaşdırır.
• Conformist. Customer dil və model Supplier olduğu kimi qəbul (məsələn, normativ reyestr).
• Partnership. İki BC sinxron olaraq dil və müqavilələri inkişaf etdirir (çox vaxt - bir komanda/roadmap).
• Shared Kernel. Ümumi minimal dil/kitabxana birlikdə versiyası; ehtiyatla istifadə edin.
• Anti-Corruption Layer (ACL). Başqalarının modellərini öz dilinə çevirən qoruyucu təbəqə.
• Open Host Service / Published Language. Version və sənədləşdirilmiş ictimai protokollar/sxemlər.

Practice: default ACL və asenkron hadisələr istifadə edin; Conformist - yalnız provayder standartı diktə edərsə, Şəred Kernel - minimal və şüurlu.

5) Sərhəd = dil + model + invariant + saxlama

• Ubiquitous Language. Nümunələrlə terminlər lüğəti.
• Aqreqatlar və invariantlar. Qaydaları kim «saxlayır» və hansı əməliyyatlara icazə verilir.
• Uyğunluq modeli. Strong/CP pul üçün, EC/causal vitrinlər üçün.
• Saxlama və indekslər. Alternativlər və SLO üçün seçilir.
• Çıxış müqavilələri. Hadisələr/komandalar, sxemlərin versiyaları, çatdırılma SLO.

Xaricdə: birbaşa SQL/cədvəl asılılığı yoxdur. Rabitə - müqavilə vasitəsilə.

6) Sərhədlər və uyğunluq (PACELC)

BC daxilində: alternativlər üçün model seçin (Wallet - Strong, Betting - Qəbulda Strong).
BC arasında: çox vaxt hadisələr və proyeksiyalar vasitəsilə eventual. Sinxron yoxlamaya ehtiyacınız varsa - əlçatmazlıqda («gizli» REST çağırışları deyil) müddəti və uğursuzluğu olan aydın komanda.

7) Antikorrupsiya təbəqəsi (ACL)

ACL-in vəzifəsi: başqasının dilini və «çirkli» məlumatları BC-yə daxil etməmək.

Mapping sxemləri: xarici 'PaymentStatus = SETTLED' → daxili 'LedgerEntry (type = Credit, reason = PsPSettle)'.
Validasiya və zənginləşdirmə: invariantların yoxlanılması, taymzonların, valyutaların normallaşdırılması.
Version: xarici müqavilənin 'schema _ version' dəstəyi, əks uyğunluq.
İdempotentlik: 'external _ id '/' operation _ id'.
Müşahidə: Trace-etiketlər 'source', 'schema _ version', 'mapping _ id', «zəhərli» mesajlar üçün DLQ.

8) Sərhədlər və məlumatlar: sahiblik, proyeksiyalar, API

Ownership: "həqiqət 'in sahibi kimdir? Yalnız sahibi qeydini dəyişir. Digər BC - read-modellər və linklər.
Proyeksiyalar: oxu üçün denormallaşdırılmış cədvəllər; hadisələrdən yenilənir.
API: komandalar (sahibində mutasiya) və sorğular (proyeksiyaları oxuyun). Başqalarının məlumatlarının «keçici» yeniləmələri yoxdur.

9) Təkamül və versiyalar

Hadisələr və API - 'schema _ version' və uyğunluq siyasəti (additive + fallback) ilə.
Blue/Green by BC: Yeni müqavilə 'v2' paralel olaraq dərc olunur 'v1', trafik tədricən tərcümə olunur.
Miqrasiya: ciddi dəyişikliklər üçün - yeni proyeksiya/xidmət, «iki fazalı svitch» oxunuşları.

10) Sınaq sərhədləri

Contract tests: BC-nin dərc olunan müqaviləyə (producer tests) əməl etdiyini və başqasının (consumer tests) düzgün başa düşdüyünü yoxlayın.
Property-based: BC daxilində aqreqatların invariantları (balans, limitlər, unikallıqlar).
inteqrasiya Chaos: gecikmələr, out-of-order, dublikatlar, schema-evolution; DLQ və təhlükəsiz redrayv var.
NFR testləri: p95/sərhəd yükü (hadisə server/ACL).

11) Sərhədlərdə müşahidə və SLO

Metriklər: throughput hadisələr/əmrlər, 'projection _ lag _ ms', 'dlq _ rate', mapping səhvləri, p95 API.
Trace: məcburi etiketlər 'bc', 'tenant _ id', 'event _ id', 'operation _ id', 'schema _ version'.
Alertlər: proyeksiyaların aşılması, komandaların uğursuzluqlarının artması, «flap» sxemi (çox 'schema _ mismatch').

12) Multi-tenant və regionlar

'tenant _ id' - sərhəddəki bütün hadisə və proyeksiyaların açarlarındadır.
Fairness: «səs-küylü» SLO qonşuları pozmamaq üçün nəşrlər/redrayv per tenant limitləri.
Residency: BC məlumatları «ev» bölgəsində yaşayır; cross-regional - aqreqatlar/hesabatlar.

13) Anti-nümunələr (bulanıq sərhəd səbəb olur)

Nəhəng «core-service». Hamısı bir yerdə → əməliyyat uğrunda mübarizə, uzun buraxılışlar, aşağı muxtariyyət.
Tablo inteqrasiyası. Başqalarının cədvəllərinə birbaşa SELECT → kövrəklik və cədvəl üzrə coupling.
Dual-write. Eyni zamanda iki BC «rahatlıq üçün» yazın → fərqlər və invariantların sabotajı.
Default Conformist. «Başqasının modelini olduğu kimi qəbul etdilər» → başqasının mənalarının sızması, təkamülün mümkünsüzlüyü.
Gizli sinxron zənglər. REST-çağırış «haradasa içəridə» heç bir açıq müqavilə və müddət olmadan → əlçatanlığa görə gözlənilməz asılılıq.

14) Konturların nümunəsi (şifahi sxem)

[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) Sərhəd seçimi üzrə mini bələdçi

1. İnvariantları formalaşdırın və onları kimin təmin edə biləcəyini müəyyənləşdirin.
2. Lüğəti təsvir edin (10-20 termin) və komandanın bir anlayışı olduğunu yoxlayın.
3. Context Map və əlaqələr növlərini çəkin.
4. Daxili və birləşmələrdə uyğunluq modelini həll edin.
5. Müqavilələri (hadisələr/komandalar) və ACL layihələndirin.
6. Müşahidə (Metrik/Trace/Alert) və DLQ/Redrive planlaşdırın.
7. İnteqrasiya üçün contract-tests və «fırtına» (chaos) keçirin.
8. governance qeyd edin: kim dil/sxem bilir, necə dəyişikliklər edilir.

16) Satış öncəsi yoxlama siyahısı

• Hər BC-də lüğət, aqreqatlar və invariantlar var.
• Context Map əlaqələri müəyyən və sənədləşdirilmiş müqavilələr.
• Hadisələr/komandalar və ACL vasitəsilə inteqrasiya, birbaşa SQL asılılığı yoxdur.
• Komandaların/hadisələrin idempotentliyi; outbox/inbox və DLQ var.
• Uyğunluq modeli (BC daxilində/arasında) qeydə alınmış və sınaqdan keçirilmişdir.
• Sxemlərin versiyalaşdırılması və uyğunluq strategiyası (v1/v2).
• Lag/səhv/performans metrikləri və alertlər konfiqurasiya edilmişdir.
• Multi-tenantlıq və data-residency siyasətlərinə əməl olunur.
• Əməliyyat pleybukları: schema-mismatch, redrive, rebuild proyeksiyaları.

17) Sürətli reseptlər

Pul və limitlər: CP və əməliyyatlar ilə ayrı BC, API yalnız komandalar, hadisələr oxu üçün həqiqətin nəticəsi kimi.
Fid/kataloqlar: EC ilə BC, projeksiyalar və cache, açıq 'freshness'.
Xarici provayderlərlə inteqrasiya: həmişə ACL, hadisələr/komandalar, sxemlərin versiyalaşdırılması vasitəsilə.
Komandanın böyüməsi: bir BC - bir komanda, komandanın «dil sahibi» və «invariant qoruyucusu» var.
Monolitin refaktorinqi: əvvəlcə müqavilələr və ACL, sonra fiziki bölgü.

Nəticə

Bounded Context yalnız bir diaqram deyil, dil, qaydalar və təkamül üsulu haqqında iş müqaviləsidir. Dəqiq sərhədlər əlaqəni azaldır, dəyişiklikləri sürətləndirir və sistemi istismarda proqnozlaşdırıla bilən edir. Məna və invariantlara görə bölün, ACL və müqavilələrin sərhədlərini qoruyun, hər şeyi metrlərlə ölçün - domen və əmr sürətlə böyüdükdə belə, arxitekturanız çevik və etibarlı qalacaq.