Ograniczony kontekst i granice domeny

Ograniczony kontekst (BC) to wyraźna granica, w której funkcjonuje jeden wszechobecny język, spójne modele i niezmienne. Wewnątrz granicy, warunki są jednoznaczne ("Zakład", "Klient", "Limit"), a poza kontekstem komunikuje się z umowami (wydarzenia/zespoły) i nie ciągnie wewnątrz innych ludzi semantyczne "ogony. "Inteligentnie wybrane granice zmniejszają łączność, upraszczają skalowanie i przyspieszają ewolucję produktów.

1) Dlaczego potrzebujemy granic

Redukcja obciążenia poznawczego. Zespół pracuje z jednym modelem i jednym językiem, a nie „całym biznesem na raz”.
Izolacja niezmienników. Zasady krytyczne (równowaga ≥ 0, unikalność logowania) żyją w jednym miejscu i są chronione przez agregaty.
Zarządzanie zmianą. Ewolucja systemu/zasad w ramach BC nie łamie sąsiada - istnieją wyraźne umowy.
Wydajność i niezawodność. W obrębie BC można wybrać odpowiedni model spójności i przechowywania; na zewnątrz - rzuty asynchroniczne.

2) Jak zidentyfikować kontekst ograniczony

1. Event Storming: zapisz zdarzenia domeny „co się stało”, a następnie polecenia „o co prosisz”, a następnie agregaty „kto gwarantuje regułę”.

2. Klastry językowe: gdzie słowa i zasady konsekwentnie pasują - potencjalny BC. Gdzie słowo „Klient” oznacza inaczej (płatnik vs player) - istnieją wyraźnie różne konteksty.

3. Niezmienne i własnościowe: czego nie można naruszyć i kto jest odpowiedzialny? Niezmienny → wewnątrz BC, który może go zagwarantować.

4. Przepływ wartości: Etapy grupowe, które często zmieniają się razem - są to kandydaci do jednego BC.

5. Struktura Org: jeśli jedna część jest wykonana przez oddzielny zespół z oddzielnymi KPI - jest to prawdopodobnie oddzielne BC (ale nie odwrotnie: struktura organizacyjna nie powinna ślepo dyktować modelu).

• Spór o terminy („zakład”, „bilet”, „okrągły” - różne znaczenia).
• Najgorętsze niezmienne „przepływa” przez usługi.
• Różne SLO i tempo zmian.
• „Dual-write” pomiędzy modułami dla atomowości.

3) Typowe konteksty (przykład domeny)

Identyfikacja/KYC - rejestracja, poziomy weryfikacji, statusy ograniczeń.
Portfel/Księga - salda, transakcje, rezerwy, waluty.
Zakłady/Zamówienia - odbiór, cytaty, obliczenia.
Gra/Runda - okrągły cykl życia, wyniki.
Bonus/Promo - memoriały, vager, konwersja.
Płatności - depozyty/wypłaty, statusy bramy płatności.
Zgodność/sprawozdawczość - sprawozdania, audyty, prezentacje regulacyjne.
Katalog/Integracja dostawcy - gry, wersje, statusy dostawców.
Analityka/Czytaj Modele - projekcje i zmaterializowane poglądy.

4) Mapa kontekstowa: jak oddziałują BC

• Klient-dostawca. Jeden BC (Dostawca) dostarcza zdarzenia/dane, drugi (Klient) dostosowuje swoje modele.
• Konformista. Klient akceptuje język i model Dostawcy (np. księga regulacyjna).
• Partnerstwo. Dwa układy BC synchronicznie zmieniają język i kontrakty (często jedno polecenie/mapa drogowa).
• Wspólne jądro. Wspólna minimalna sublanguage/biblioteka, w wersji wspólnie; ostrożnie używać.
• Warstwa antykorupcyjna (ACL). Warstwa ochronna, która przekłada modele innych ludzi na własny język.
• Usługa Open Host/Język opublikowany. Protokoły/programy publiczne, zmienione i udokumentowane.

Praktyka: domyślnie użyj ACL i zdarzeń asynchronicznych; Conformist - tylko wtedy, gdy dostawca dyktuje standard, Wspólne jądro - minimalnie i świadomie.

5) Związany = język + model + niezmienne + przechowywanie

• Wszechobecny język. Słownik terminów z przykładami.
• Kruszywa i niezmienne. Kto „trzyma” zasady i jakie operacje są dozwolone.
• Model spójności. Silny/CP dla pieniędzy, EC/przyczynowy dla sklepów.
• Przechowywanie i indeksy. Wybrane dla stałych i SLO.
• Umowy wyjścia. Zdarzenia/polecenia, wersje schematu, SLO dostawy.

Na zewnątrz: brak bezpośrednich zależności SQL/table. Komunikacja - poprzez umowę.

6) Granice i spójność (PACELC)

Wewnątrz BC: wybierz model dla osób niezmiennych (Portfel - Strong, Betting - Strong w recepcji).
Między PB: Najczęściej ostatecznie poprzez wydarzenia i projekcje. Jeśli potrzebna jest weryfikacja synchroniczna, wyraźne polecenie z terminem i awarią, gdy jest niedostępne (nie „ukryte” połączenie REST).

7) Warstwa antykorupcyjna (ACL)

Zadaniem ACL jest nie wpuszczać do PC czyjegoś języka i brudnych danych.

Mapowanie schematu: zewnętrzny 'Status' = SETTLED '→ wewnętrzne' LedgerEntry (type = Credit, reason = PsPSettle) '.
Walidacja i wzbogacanie: weryfikacja niezmienników, normalizacja stref czasowych, waluty.
Wersioning: wsparcie dla kontraktu zewnętrznego 'schema _ version', kompatybilność wsteczna.
Idempotencja: przez 'external _ id'/' operation _ id'.
Obserwowalność: znaczniki śladowe 'source', 'schema _ version', 'mapping _ id', DLQ dla' trujących 'wiadomości.

8) Granice i dane: własność, prognozy, API

Własność: Kto jest właścicielem „prawdy”? Tylko właściciel zmienia rekord. Reszta BC - czytaj-modele i linki.
Projekcje: denormalizowane tabele do odczytów; są aktualizowane z wydarzeń.
API: polecenia (mutować w właścicielu) i żądania (odczytać projekcje). Brak „end-to-end” aktualizacji danych innych ludzi.

9) Ewolucja i wersje

Zdarzenia i interfejsy API - z 'schema _ version' i zasadami kompatybilności (dodatek + fallback).
Blue/Green by BC: nowa umowa „v2” jest publikowana równolegle do „v1”, ruch jest stopniowo przenoszony.
Migracja: dla dużych zmian - nowa projekcja/usługa, „dwufazowy przełącznik” odczytów.

10) Badanie graniczne

Testy kontraktowe: sprawdzenie zgodności BC z opublikowaną umową (testy producenta) i prawidłowe zrozumienie cudzego (testy konsumenckie).
Nieruchomości: niezmienne agregaty w ramach BC (saldo, granice, wyjątkowość).
Chaos na temat integracji: opóźnienia, nieporządek, duplikaty, schemat ewolucji; obecność DLQ i bezpieczne przeredagowanie.
Testy NFR: p95/maksymalne obciążenie na granicy (serwer zdarzeń/ACL).

11) Obserwowalność i SLO według granicy

Mierniki: przepustowość zdarzeń/poleceń, 'projection _ lag _ ms', 'dlq _ rate', błędy mapowania, p95 API.
Śledzenie: obowiązkowe tagi 'bc',' lokator _ id', 'event _ id',' operation _ id', 'schema _ version'.
Alerty: przekroczenie opóźnienia projekcji, zwiększenie awarii poleceń, schemat „klapa” (wiele 'schema _ mismatch').

12) Wieloosobowy najemca i regiony

"lokator _ id' - w kluczykach wszystkich zdarzeń i projekcji na granicy.
Uczciwość: Wydawanie/przerobienie limitów na najemcę, aby utrzymać „hałas” przed wykolejeniem SLO sąsiadów.
Miejsce zamieszkania: dane BC mieszkają w regionie „domowym”; cross-regional - agregaty/sprawozdania.

13) Anty-wzory (w wyniku niewyraźnej granicy)

Gigantyczny serwis rdzeniowy. "Wszystko w jednym miejscu → walka o transakcje, długie zwolnienia, niska autonomia.
Integracje tabelaryczne. WYBIERZ linie do tabel obcych → kruchość i sprzężenie zgodnie z schematem.
Podwójne pisanie. Jednocześnie, pisanie w dwóch BC „dla wygody” → rozbieżności i sabotaż niezmienników.
Conformist domyślnie. „Przyjął model kogoś innego, jak to jest” → wyciek znaczeń innych ludzi, niemożliwość ewolucji.
Ukryte synchroniczne połączenia. REST call „gdzieś w środku” bez wyraźnej umowy i terminu → nieoczekiwana zależność od dostępności.

14) Przykład konturów (schemat słowny)

[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-przewodnik dla wyboru granicy

1. Formułować niezmienników i określić, kto może im zagwarantować.
2. Opisz słownik (10-20 terminów) i upewnij się, że zespół ma to samo zrozumienie.
3. Narysuj mapę kontekstową i typy relacji.
4. Rozwiązać model spójności wewnątrz i na stawach.
5. Kontrakty projektowe (zdarzenia/polecenia) i ACL.
6. Plan obserwacji (mierniki/śledzenie/alerty) i DLQ/redrive.
7. Uruchom testy kontraktowe i chaos dla integracji.
8. Fix governance: kto jest właścicielem języka/systemu, jak dokonywane są zmiany.

16) Lista kontrolna przedsprzedaży

• Każdy PB posiada słownictwo, agregaty i niezmienne.
• Relacje są zdefiniowane na mapie kontekstowej, a umowy są udokumentowane.
• Integracja za pomocą zdarzeń/poleceń i ACL, brak bezpośrednich zależności SQL.
• Dowództwo/impreza idempotencja; istnieje skrzynka odbiorcza/skrzynka odbiorcza i DLQ.
• Model spójności (wewnątrz/między BC) stały i przetestowany.
• Strategia weryfikacji i kompatybilności schematu (v1/v2).
• Mierniki lag/error/performance i alerty są konfigurowane.
• Egzekwowane są zasady dotyczące wielozadaniowości i rezydencji danych.
• Operacyjne playbooks: schemat-niedopasowanie, redrive, odbudować projekcje.

17) Szybkie przepisy kulinarne

Pieniądze i limity: oddzielne BC z CP i transakcje, API tylko polecenia, wydarzenia jako wynik prawdy dla odczytów.
Kanały/katalogi: BC z EC, projekcje i pamięć podręczną, wyraźna „świeżość”.
Integracje z zewnętrznymi dostawcami: zawsze za pośrednictwem ACL, zdarzeń/poleceń, wersji schematu.
Wzrost zespołu: Jeden PB jest jednym zespołem, zespół ma „właściciela języka” i „opiekuna niezmienników”.
Monolith refaktoring: kontrakty i ACL najpierw, a następnie fizyczne rozdzielenie.

Wnioski

Ograniczony kontekst to nie tylko schemat, ale porozumienie robocze w sprawie języka, zasad i sposobu ewolucji. Wyraźne granice zmniejszają łączność, zmianę prędkości i sprawiają, że system jest przewidywalny do działania. Oddzielne przez znaczenie i niezmienne, chronić granice ACL i kontrakty, mierzyć wszystko za pomocą metryk - a Twoja architektura pozostanie elastyczna i niezawodna nawet przy szybkim rozwoju domeny i zespołu.