Context delimitat și limite de domeniu

Contextul delimitat (BC) este o limită clară în care funcționează un singur limbaj omniprezent, modele consistente și invarianți. În interiorul frontierei, termenii sunt lipsiți de ambiguitate („Pariu”, „Client”, „Limită”), iar în afara contextului comunică cu contractele (evenimente/echipe) și nu trage în cozile semantice ale altor persoane. "Limitele alese inteligent reduc conectivitatea, simplifică scalarea și accelerează evoluția produsului.

1) De ce avem nevoie de frontiere

Reducerea sarcinii cognitive. Echipa lucrează cu un model și o limbă, nu cu „întreaga afacere deodată”.
Izolarea invarianţilor. Regulile critice (soldul ≥ 0, unicitatea de conectare) trăiesc într-un singur loc și sunt protejate de agregate.
Managementul schimbării. Evoluția schemei/normelor în cadrul BC nu rupe vecinul - există contracte explicite.
Performanţă şi fiabilitate. În cadrul unei BC, se poate alege un model adecvat de consistență și depozitare; exterior - proiecții asincrone.

2) Cum să identificați contextul delimitat

1. Event Storming: notați evenimentele din domeniu „ce sa întâmplat”, apoi comenzile „ce cereți să faceți”, apoi agregatele „cine garantează regula”.

2. Clustere de limbi: în cazul în care cuvintele și regulile se potrivesc în mod consecvent - potențial BC. În cazul în care cuvântul „Client” înseamnă diferit (plătitor vs jucător) - există în mod clar contexte diferite.

3. Invarianții și proprietatea: ce nu poate fi încălcat și cine este responsabil? Invariantul → în interiorul BC care îl poate garanta.

4. Fluxul de valoare: Pași de grup care se schimbă adesea împreună - aceștia sunt candidați pentru un BC.

5. Structura Org: dacă o parte este făcută de o echipă separată cu KPI-uri separate - aceasta este probabil o BC separată (dar nu invers: structura organizațională nu ar trebui să dicteze orbește modelul).

• Dispută despre termeni („pariu”, „bilet”, „rundă” - sensuri diferite).
• Cele mai tari „curge” invariant prin intermediul serviciilor.
• Diferite SLO-uri și ritmul schimbării.
• „Dual-write” între module de dragul atomicităţii.

3) Contexte tipice (exemplu de domeniu)

Identitate/KYC - înregistrarea, nivelurile de verificare, stările de restricție.
Portofel/Ledger - solduri, tranzacții, rezerve, valute.
Pariuri/comenzi - recepție, cotații, calcul.
Joc/rundă - ciclu de viață rotund, rezultate.
Bonus/Promo - acumulări, vager, conversie.
Plăți - depozite/retrageri, statusuri gateway de plată.
Conformitate/Raportare - rapoarte, audituri, vitrine de reglementare.
Catalog/Integrare Furnizor - jocuri, versiuni, statusuri ale furnizorilor.
Analytics/Read Models - proiecții și vizualizări materializate.

4) Harta contextului: cum interacționează BCs

• Client-furnizor. Un BC (Furnizor) livrează evenimente/date, celălalt (Client) își ajustează modelele.
• Conformist. Clientul acceptă limba furnizorului și modelul așa cum este (de ex. registru de reglementare).
• Parteneriat. Două BCs evoluează sincron limbaj și contracte (de multe ori o comandă/foaie de parcurs).
• Kernel partajat. Sublanguaj/bibliotecă minimă comună, versionată în comun; utilizați cu atenție.
• Stratul anticorupție (ACL). Un strat protector care traduce modelele altora în limba lor.
• Open Host Service/Limba publicată. Protocoale/scheme publice, versionate și documentate.

Practică: Utilizați ACL-uri și evenimente asincrone în mod implicit; Conformist - numai dacă furnizorul dictează standardul, Kernel partajat - minim și conștient.

5) Legat = limbă + model + invarianți + stocare

• Limba omniprezentă. Dicționar de termeni cu exemple.
• Agregate și invarianți. Cine „deține” regulile și ce operațiuni sunt permise.
• Model de consistență. Strong/CP pentru bani, CE/cauzal pentru storefronts.
• Depozitare și indici. Selectat pentru invarianți și SLO.
• Contracte de ieșire. Evenimente/comenzi, versiuni schema, SLO-uri de livrare.

În afara: nu există dependențe directe SQL/tabel. Comunicare - printr-un contract.

6) Limite și consecvență (PACELC)

În interiorul BC: alegeți un model pentru invarianți (Portofel - Puternic, Pariuri - Puternic la recepție).
Între BC: Cel mai adesea eventual prin evenimente și proiecții. Dacă este necesară verificarea sincronă, o comandă explicită cu un termen limită și eșec atunci când nu este disponibilă (nu un apel „ascuns” REST).

7) Strat anticorupție (ACL)

Sarcina ACL nu este de a lăsa limbajul altcuiva și datele murdare în interiorul BC.

Schema de cartografiere: extern 'PaymentStatus = SETTLED' → intern 'LedgerEntry (tip = Credit, motiv = PsPSettle)'.
Validarea și îmbogățirea: verificarea invarianților, normalizarea zonelor orare, valutelor.
Versioning: suport pentru 'schema _ version' contract extern, compatibilitate înapoi.
Idempotence: prin 'external _ id'/' operation _ id'.
Observabilitate: urme de etichete "sursă", "schema _ versiune", "mapping _ id', DLQ pentru mesaje" otrăvitoare ".

8) Limite și date: proprietate, proiecții, API

Proprietatea: Cine deține „adevărul”? Doar proprietarul schimbă înregistrarea. Restul BC - read-modele și link-uri.
Proiecții: tabele denormalizate pentru citiri; sunt actualizate de la evenimente.
API: comenzi (mutații în proprietar) și cereri (citiți proiecțiile). Nu există actualizări "end-to-end' ale datelor altor persoane.

9) Evoluție și versiuni

Evenimente și API-uri - cu 'schema _ version' și politica de compatibilitate (aditiv + rezervă).
Albastru/Verde de BC: noul contract „v2” este publicat paralel cu „v1”, traficul este transferat treptat.
Migrații: pentru schimbări majore - o nouă proiecție/serviciu, un „comutator în două faze” de lecturi.

10) Testarea granițelor

Teste de contract: verificarea conformității BC cu contractul publicat (testele de producător) și înțelegerea corectă a altora (testele de consum).
Bazat pe proprietate: invarianți de agregate în cadrul BC (echilibru, limite, unicitate).
Haos pe integrari: intarzieri, out-of-order, duplicate, schema-evolutie; prezența DLQ și retrave în condiții de siguranță.
Teste NFR: p95/vârf de încărcare la frontieră (event server/ACL).

11) Observabilitate și SLO după limită

Valori: transfer de evenimente/comenzi, 'projection _ lag _ ms',' dlq _ rate ', erori de mapare, p95 API.
Urmărire: etichete obligatorii 'bc', 'tenant _ id',' event _ id', 'operation _ id',' schema _ version '.
Alerte: depășirea decalajului de proiecție, creșterea eșecurilor de comandă, schema „clapă” (multe „schemă _ nepotrivire”).

12) Multi-chiriaș și regiuni

'tenant _ id' - în cheile tuturor evenimentelor și proiecțiilor de pe frontieră.
Corectitudine: Publicarea/redesenarea limitelor per chiriaș pentru a menține „zgomotul” față de SLO-urile vecinilor deraiați.
Rezidență: datele BC trăiesc într-o regiune „acasă”; transregional - agregate/rapoarte.

13) Anti-modele (care rezultă în limite neclare)

Gigant "core-service. "Totul într-un singur loc → lupta pentru tranzacții, eliberări lungi, autonomie scăzută.
Integrări tabelare. SELECTAȚI linii la tabele străine → fragilitate și cuplare în conformitate cu schema.
Scriere dublă. În același timp, scrierea în două î.Hr. „pentru comoditate” → discrepanțe și sabotarea invarianților.
Conformist în mod implicit. „A acceptat modelul altcuiva așa cum este” → scurgerea semnificațiilor altor oameni, imposibilitatea evoluției.
Apeluri sincrone ascunse. RESTUL numesc „undeva în interior” fără un contract explicit și un termen limită → o dependență neașteptată de disponibilitate.

14) Exemplu de contururi (schema verbală)

[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) Mini-ghid pentru selectarea frontierei

1. Formulați invarianți și determinați cine le poate garanta.
2. Descrieți dicționarul (10-20 termeni) și asigurați-vă că echipa are aceeași înțelegere.
3. Desenați harta contextuală și tipurile de relații.
4. Rezolvați modelul de consistență în interiorul și la articulații.
5. Contracte de proiectare (evenimente/comenzi) și ACL-uri.
6. Plan pentru observabilitate (valori/urmărire/alerte) și DLQ/redrive.
7. Efectuați teste de contract și haos pentru integrare.
8. Fixați guvernanța: cine deține limba/schema, cum se fac modificările.

16) Lista de verificare pre-vânzare

Fiecare BC are un vocabular, agregate și invarianți.

• Relațiile sunt definite pe Harta Contextului și contractele sunt documentate.
• Integrarea prin evenimente/comenzi și ACL-uri, fără dependențe SQL directe.
• Command/event idempotency; există outbox/inbox și DLQ.
• Modelul de consistență (intra/inter BC) fix și testat.
• Schema strategiei de versionare și compatibilitate (v1/v2).
• Sunt configurate valori și alerte de lag/eroare/performanță.
• Politicile multi-chirie și de rezidență a datelor sunt aplicate.
• Playbook-uri de operare: schema-nepotrivire, redrive, reconstrui proiecții.

17) Rețete rapide

Bani și limite: BC separat cu CP și tranzacții, API doar comenzi, evenimente ca rezultat al adevărului pentru lecturi.
Feed-uri/directoare: BC cu CE, proiecții și memorie cache, „prospețime” explicită.
Integrarea cu furnizorii externi: întotdeauna prin ACL-uri, evenimente/comenzi, versioning schema.
Creșterea echipei: One BC este o echipă, echipa are un „proprietar de limbă” și un „deținător de invarianți”.
Refactorizarea Monolith: contractele și ACL-urile mai întâi, apoi separarea fizică.

Concluzie

Contextul delimitat nu este doar o diagramă, ci un acord de lucru privind limbajul, regulile și modul de evoluție. Limitele clare reduc conectivitatea, schimbarea vitezei și fac sistemul previzibil să funcționeze. Separați prin înțeles și invarianți, protejați limitele ACL și contractele, măsurați totul cu valori - iar arhitectura dvs. va rămâne flexibilă și fiabilă chiar și cu creșterea rapidă a domeniului și a echipei.