Sınırlı Bağlam ve Alan Sınırları

Sınırlı Bağlam (BC), tek bir Ubiquitous Dilinin, tutarlı modellerin ve değişmezlerin çalıştığı açık bir sınırdır. Sınırın içinde, terimler belirsizdir ("Bahis", "Müşteri", "Sınır") ve bağlamın dışında sözleşmelerle (olaylar/takımlar) iletişim kurar ve başkalarının semantik "kuyruklarının içine çekmez. Akıllıca seçilmiş sınırlar, bağlantıyı azaltır, ölçeklendirmeyi basitleştirir ve ürün gelişimini hızlandırır.

1) Neden sınırlara ihtiyacımız var

Bilişsel yük azaltma. Ekip,'tüm işi bir kerede'değil, bir model ve bir dil ile çalışır.
Değişmezlerin izolasyonu. Kritik kurallar (denge ≥ 0, oturum açma benzersizliği) tek bir yerde yaşar ve toplamlarla korunur.
Değişim yönetimi. BC içindeki şema/kuralların evrimi komşuyu kırmaz - açık sözleşmeler vardır.
Performans ve güvenilirlik. Bir BC içinde, uygun bir tutarlılık modeli ve depolama seçilebilir; Dışarıda - asenkron projeksiyonlar.

2) Sınırlı Bağlam nasıl tanımlanır

1. Olay Fırtınası: etki alanı olaylarını'ne oldu ", sonra'ne yapmak istiyorsun" komutlarını, sonra da "kuralı kim garanti ediyor" kümelerini yazın.

2. Dil kümeleri: kelimelerin ve kuralların sürekli olarak eşleştiği yer - potansiyel BC. "Müşteri" kelimesinin farklı olduğu yerlerde (ödeme yapan ve oyuncu) - açıkça farklı bağlamlar vardır.

3. Değişmezler ve mülkiyet: ihlal edilemeyen ve sorumlu olan nedir? BC'nin içinde bunu garanti edebilecek değişmez olan.

4. Değer akışı: Genellikle birlikte değişen grup adımları - bunlar bir BC için adaylardır.

5. Org yapısı: Bir parça ayrı KPI'lara sahip ayrı bir ekip tarafından yapılırsa - bu muhtemelen ayrı bir BC'dir (ancak tersi değildir: organizasyon yapısı körü körüne modeli dikte etmemelidir).

• Terimler hakkında anlaşmazlık ("bahis", "bilet", "tur" - farklı anlamlar).
• En sıcak değişmez "akar" hizmetler arasında.
• Farklı SLO'lar ve değişim hızı.
• Atomiklik uğruna modüller arasında "çift yazma".

3) Tipik bağlamlar (alan örneği)

Kimlik/KYC - kayıt, doğrulama seviyeleri, kısıtlama durumları.
Cüzdan/Defter - bakiyeler, işlemler, rezervler, para birimleri.
Bahis/Siparişler - alım, teklif, hesaplama.
Oyun/Yuvarlak - yuvarlak yaşam döngüsü, sonuçlar.
Bonus/Promosyon - tahakkuk, vager, dönüşüm.
Ödemeler - para yatırma/çekme, ödeme ağ geçidi durumları.
Uyumluluk/Raporlama - raporlar, denetimler, düzenleyici vitrinler.
Katalog/Sağlayıcı Entegrasyonu - oyunlar, sürümler, sağlayıcıların durumları.
Analitik/Okuma Modelleri - projeksiyonlar ve somutlaştırılmış görünümler.

4) Bağlam Haritası: BC'lerin nasıl etkileşime girdiği

• Müşteri-Tedarikçi. Bir BC (Tedarikçi) olayları/verileri sunar, diğeri (Müşteri) modellerini ayarlar.
• Konformist. Müşteri Tedarikçi dilini ve modelini olduğu gibi kabul eder (örn. düzenleyici defter).
• Ortaklık. İki BC, dili ve sözleşmeleri eşzamanlı olarak geliştirir (genellikle bir komut/yol haritası).
• Paylaşılan çekirdek. Ortak minimal alt dil/kütüphane, ortaklaşa sürüm; dikkatli kullanın.
• Yolsuzlukla Mücadele Katmanı (ACL) Diğer insanların modellerini kendi dillerine çeviren koruyucu bir katman.
• Host Service/Published Language'i açın. Kamu protokolleri/şemaları, sürüm ve belgelenmiş.

Uygulama: Varsayılan olarak ACL'leri ve asenkron olayları kullanın; Konformist - yalnızca sağlayıcı standardı, Paylaşılan Çekirdeği - minimal ve bilinçli olarak dikte ederse.

5) Bağlı = dil + model + değişmezler + depolama

• Her yerde konuşulan bir dil. Örneklerle terimler sözlüğü.
• Agregalar ve değişmezler. Kuralları kim "tutar've hangi işlemlere izin verilir.
• Tutarlılık modeli. Para için güçlü/CP, vitrinler için EC/nedensel.
• Depolama ve indeksler. Değişmezler ve SLO için seçildi.
• Sözleşmelerden çıkın. Olaylar/komutlar, şema sürümleri, teslim SLO'lar.

Dış: doğrudan SQL/tablo bağımlılıkları yok. İletişim - bir sözleşme yoluyla.

6) Sınırlar ve Tutarlılık (PACELC)

BC'nin içinde: değişmezler için bir model seçin (Cüzdan - Güçlü, Bahis - Resepsiyonda güçlü).
BC arasında: En sık olaylar ve projeksiyonlar yoluyla nihai. Eşzamanlı doğrulama gerekiyorsa, son teslim tarihi olan ve kullanılamadığında başarısız olan açık bir komut ("gizli'bir REST çağrısı değil).

7) Yolsuzlukla mücadele katmanı (ACL)

ACL'nin görevi, bir başkasının dilinin ve kirli verilerinin BC'ye girmesine izin vermemektir.

Şema eşleme: harici 'PaymentStatus = SETTED' - dahili 'LedgerEntry (type = Credit, reason = PsPSettle)'.
Doğrulama ve zenginleştirme: değişmezlerin doğrulanması, zaman dilimlerinin normalleştirilmesi, para birimleri.
Sürüm oluşturma: 'schema _ version' dış sözleşme desteği, geriye dönük uyumluluk.
Idempotence: 'external _ id'/' operation _ id'ile.
Gözlemlenebilirlik: trace etiketleri 'source', 'schema _ version', 'mapping _ id', 'zehirli' mesajlar için DLQ.

8) Sınırlar ve veriler: sahiplik, projeksiyonlar, API

Mülkiyet: "Gerçeğin" sahibi kim? Sadece sahibi kaydı değiştirir. BC'nin geri kalanı - okuma modelleri ve bağlantılar.
Projeksiyonlar: Okumalar için denormalize tablolar; olaylardan güncellenir.
API: komutlar (sahibinde mutasyona uğrar) ve istekler (projeksiyonları okur). Başkalarının verilerinin "uçtan uca" güncellenmesi yok.

9) Evrim ve versiyonlar

Olaylar ve API'ler - 'schema _ version've uyumluluk politikası ile (additive + fallback).
BC tarafından Mavi/Yeşil: yeni sözleşme 'v2', 'v1'e paralel olarak yayınlanır, trafik kademeli olarak aktarılır.
Göçler: büyük değişiklikler için - yeni bir projeksiyon/hizmet, okumaların "iki fazlı anahtarı".

10) Sınır testi

Sözleşme testleri: BC'nin yayınlanan sözleşmeye (üretici testleri) uyup uymadığını kontrol etmek ve bir başkasınınkini (tüketici testleri) doğru bir şekilde anlamak.
Özellik tabanlı: BC içindeki agregaların değişmezleri (denge, sınırlar, benzersizlik).
Entegrasyonlarda kaos: gecikmeler, sıra dışı, kopyalar, şema-evrim; DLQ ve güvenli redrave varlığı.
NFR testleri: Sınırda p95/tepe yük (olay sunucusu/ACL).

11) Sınırlara göre gözlemlenebilirlik ve SLO

Metrikler: olayların/komutların çıktısı, 'projection _ lag _ ms', 'dlq _ rate', haritalama hataları, p95 API.
İzleme: zorunlu etiketler 'bc', 'tenant _ id', 'event _ id', 'operation _ id', 'schema _ version'.
Uyarılar: projeksiyon gecikmesini aşmak, komut hatalarını artırmak, şema "flap" (birçok 'schema _ mismatch').

12) Çok kiracı ve bölgeler

'tenant _ id' - sınırdaki tüm olayların ve projeksiyonların anahtarlarında.
Adalet: Komşuların SLO'larını raydan çıkarmaktan "gürültülü" tutmak için kiracı başına yayın/yeniden çizme sınırları.
İkamet: BC verileri bir'ev "bölgesinde yaşıyor; Bölgeler arası - kümeler/raporlar.

13) Anti-desenler (bulanık sınır ile sonuçlanır)

Dev "çekirdek servis. "Her şey tek bir yerde - işlemler için mücadele, uzun sürümler, düşük özerklik.
Tablo entegrasyonları. Yabancı tablolara SELECT hatları - şemaya göre kırılganlık ve kuplaj.
Çift yazma. Aynı zamanda, iki BC'de "kolaylık için" yazmak - tutarsızlıklar ve değişmezlerin sabotajı.
Varsayılan olarak konformist. "Başkasının modelini olduğu gibi kabul etti" - diğer insanların anlamlarının sızması, evrimin imkansızlığı.
Gizli eş zamanlı aramalar. REST, açık bir sözleşme ve son tarih olmadan "içeride bir yerde" çağırır - kullanılabilirliğe beklenmedik bir bağımlılık.

14) Konturların örneği (sözel şema)

[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ınır seçimi için mini kılavuz

1. Değişmezleri formüle edin ve bunları kimin garanti edebileceğini belirleyin.
2. Sözlüğü tanımlayın (10-20 terim) ve ekibin aynı anlayışa sahip olduğundan emin olun.
3. Bağlam Haritasını ve ilişki türlerini çizin.
4. Derzlerin içindeki ve içindeki tutarlılık modelini çözün.
5. Tasarım sözleşmeleri (olaylar/komutlar) ve ACL'ler.
6. Gözlemlenebilirliği planlayın (metrikler/izleme/uyarılar) ve DLQ/redrive.
7. Entegrasyon için sözleşme testleri ve kaos çalıştırın.
8. Yönetişimi düzeltin: Dilin/planın sahibi, değişikliklerin nasıl yapıldığı.

16) Satış öncesi kontrol listesi

• Her BC'nin bir kelime hazinesi, kümeleri ve değişmezleri vardır.
• İlişkiler Bağlam Haritasında tanımlanır ve sözleşmeler belgelenir.
• Olaylar/komutlar ve ACL'ler aracılığıyla entegrasyon, doğrudan SQL bağımlılıkları yok.
• Komut/olay idempotency; Giden/gelen kutusu ve DLQ vardır.
• Tutarlılık modeli (intra/inter BC) sabit ve test edilmiştir.
• Şema sürüm oluşturma ve uyumluluk stratejisi (v1/v2).
• Gecikme/hata/performans ölçümleri ve uyarıları yapılandırılmıştır.
• Çok kiracılık ve veri ikamet politikaları uygulanmaktadır.
• Çalışma oyun kitapları: şema-uyumsuzluk, redrive, projeksiyonları yeniden oluşturma.

17) Hızlı tarifler

Para ve limitler: CP ve işlemler ile ayrı BC, API sadece komutlar, okumalar için gerçeğin sonucu olarak olaylar.
Beslemeler/dizinler: EC ile BC, projeksiyonlar ve önbellek, açık 'tazelik'.
Dış sağlayıcılarla entegrasyonlar: her zaman ACL'ler, olaylar/komutlar, şema sürümleri aracılığıyla.
Takım büyümesi: Bir BC bir takımdır, takımın bir "dil sahibi've" değişmezlerin koruyucusu "vardır.
Monolit refactoring: önce sözleşmeler ve ACL'ler, sonra fiziksel ayırma.

Sonuç

Sınırlı Bağlam sadece bir diyagram değil, dil, kurallar ve evrim yolu üzerinde çalışan bir anlaşmadır. Net sınırlar, bağlantıyı, hız değişimini azaltır ve sistemin çalışmasını öngörülebilir kılar. Anlam ve değişmezlerle ayırın, ACL sınırlarını ve sözleşmelerini koruyun, her şeyi metriklerle ölçün - ve mimariniz alanın ve ekibin hızlı büyümesiyle bile esnek ve güvenilir kalacaktır.