Bounded context ayirma

Domain-Driven Design'da bounded context, belirli bir is alaninda geçerli olan model sinirini tanimlar. Ayni kavram farklı context'lerde farklı anlama gelebilir: bir context'te Customer bir CRM varligi iken baska bir context'te fatura adresi ve odeme profili on plandadir. Bounded context ayirma, bu anlam farkliliklarini kod ve ekip sinirlarina yansitmanin temel aracidir.

Ubiquitous language ve context sınırları

Her bounded context kendi ortak diline sahiptir. Ekip, ürün sahibi ve domain uzmanlari ayni terimleri ayni anlamda kullanır. Context sınırı asildiginda terminoloji catismasi baslar: 'Order' bir yerde siparis, baska yerde is emri anlamina gelir. Context map bu iliskileri gorsellestirir.

• Partnership: Iki ekip birlikte geliştirir, ortak cikar.
• Customer-Supplier: Downstream upstream'e bağımlı, sözleşme net.
• Conformist: Downstream upstream modelini olduğu gibi kabul eder.
• Anti-corruption layer: Dis model ic modele cevrilir.
• Shared kernel: Sinirli paylasilan kod, dikkatli yönetim gerekir.

Context haritalama süreci

Context discovery workshop'lari ile baslar: domain uzmanlari ve geliştiriciler bir araya gelir, event storming veya domain storytelling ile alt domainler cikarilir. Her alt domain icin bagimsiz degisebilirlik ve is onceligi degerlendirilir. Yüksek bagimsizlik ve karmasiklik bounded context adayi olur.

1. Is sureclerini ve olaylari listele
2. Terminoloji catismalarini isaretle
3. Onerilen context sinirlarini ciz
4. Context'ler arasi iliskileri haritala
5. Ekip sahipligini context bazinda ata

Subdomain turleri

Eric Evans'a gore subdomainler core, supporting ve generic olarak siniflanir. Core subdomain rekabet avantaji sağlar, en iyi ekip burada çalışır. Supporting subdomain is icin gerekli ama farklilastirici degil. Generic subdomain hazir çözüm veya outsource edilebilir (örneğin e-posta).

Core context koruma

Core bounded context'e dis sistemlerin modeli birebir sokulmamali. ERP veya legacy entegrasyonlar anti-corruption layer ile izole edilir. Core model zengin domain mantigi tasir; anemic yapidan kacinilir.

Fiziksel vs mantiksal ayrim

Bounded context mantiksal bir sinirdir; tek monolit icinde farklı namespace ve modül olarak da yasayabilir. Mikroservise geciste her context ayri deployable birim olabilir. Erken asamada fiziksel ayirim maliyeti yüksektir; mantiksal sınırlar once netlestirilmeli.

Modules/
  Sales/           # Sales bounded context
    Domain/
    Application/
  Billing/         # Billing bounded context
    Domain/
    Application/
  SharedKernel/    # Minimal shared types only

Context'ler arasi iletişim

Dogrudan veritabanı paylasimi context bagimsizligini bozar. Tercih edilen yöntemler: domain event, integration event, REST/gRPC API veya mesaj kuyrugu. Event payload contract versioning ile yönetilir. Sync cagrilar basit senaryolarda yeterli olabilir ancak coupling artirir.

Integration event tasarımı

Integration event'ler dis dunyaya açık sozlesmedir. Alanlar minimal ve evrimsel olmali; yeni alan eklemek breaking degildir, alan kaldirmak breaking'dir. Event schema registry veya contract test ile uyumluluk korunur.

public sealed record OrderPlacedIntegrationEvent(
    Guid OrderId,
    string CustomerReference,
    decimal TotalAmount,
    DateTime OccurredAt);

Veri sahipligi ve replikasyon

Her bounded context kendi verisinin sahibidir. Baska context'in verisine ihtiyaç duyarsa read model replikasyonu veya sorgu API'si kullanılır. Customer context müşteri master verisini tutar; Order context yalnizca customer ID ve snapshot bilgi tasir.

• Single writer: Her aggregate tek context'te yazilir.
• Read replica: Diger context'ler eventual consistency ile okur.
• Snapshot: Gecmis an icin dondurulmus veri, tutarlılık icin.

Ekip topolojisi

Conway yasasi geregi yazılım yapisi organizasyon yapisini yansitir. Bounded context basina bir ekip (two-pizza team) ideal hedeftir. Context sınırları API ve event sozlesmeleriyle formalize edilir. Ortak standartlar (log format, trace, güvenlik) platform ekibi tarafindan sağlanır.

Legacy sistemlerle sınır cizme

Mevcut monolit icinde context ayirimi namespace, assembly ve veritabanı schema ayrımı ile baslar. Legacy modül facade arkasina alinir; yeni özellikler yeni context'te geliştirilir. Strangler fig ile zamanla eski kod emekli edilir.

Big ball of mud'dan çıkış

Tüm kodu bir anda bolmek risklidir. Öncelikli context secilir (genelde en yüksek is degeri veya en cok değişen alan). Diger bolgeler geçici olarak 'legacy context' olarak isaretlenir ve sınırlar yavas genisletilir.

Context birlestirme ve bolme kararlari

Baslangicta ayirdiginiz context'ler zamanla birlestirilebilir: cok düşük değişim, ayni ekip sahipligi ve sik senkron iletişim birlestirme sinyalidir. Tersine bolme: context icinde farklı değişim hizlari ve terminoloji catismasi buyudukce bolme gundeme gelir. ADR ile kararlar kayıt altina alinir.

Test ve contract dogrulama

Context'ler arasi consumer-driven contract testleri (Pact gibi) API ve event sozlesmelerinin bozulmadigini garanti eder. Her context kendi test piramidine sahiptir; entegrasyon testleri sınır uzerinde çalışır.

Güvenlik ve yetkilendirme sınırları

Kimlik ve erişim yönetimi genelde ayri bir context veya generic subdomain olarak modellenir. Diger context'ler token veya claim bazli yetkilendirme kullanır. Cross-context yetki kontrolu merkezi policy servisi ile sağlanabilir.

Ölçeklendirme kararlari

Her context bagimsiz olceklendirilir: Order context yüksek trafik alirken Catalog context read-heavy cache ile calisabilir. Context sınırları net oldugunda bu kararlar bagimsiz verilir; monolit icinde bile modül bazli kaynak ayirimi yapilabilir.

Yaygın hatalar

Tek 'Customer' entity'sini tüm sistemde paylasmak. Context'leri sadece klasor adi olarak görmek, iletişim sozlesmesi tanimlamamak. Cok erken mikroservis bolme. Shared kernel'in kontrolsuz buyumesi. Event storming yapmadan tahmini sınır cizme.

Pratik kontrol listesi

1. Is olaylari ve terminoloji workshop'u yapildi mi?
2. Her context icin ubiquitous language dokumani var mi?
3. Context map güncel mi?
4. Veri sahipligi ve iletişim kanali net mi?
5. Legacy entegrasyonlar ACL ile korunuyor mu?
6. Ekip sahipligi context ile hizali mi?

Özet

Bounded context ayirma, domain karmasikligini yönetilebilir parcalara bolmenin disiplinli yoludur. Mantiksal sınırlar once netlestirilir, iletişim event ve API ile formalize edilir, ekip yapisi bu sinirlara gore duzenlenir. Mikroservis veya moduler monolit seçimi bu temel uzerine insa edilir; context haritasi olmadan yapılan bolme genelde başarısız olur.

Üretim ortaminda mimari disiplin

Mimari kararlar yalnizca tasarım dokumaninda kalmamali; CI pipeline, code review checklist ve otomatik analiz araclari ile gunluk geliştirme akisina gomulmelidir. Bağımlılık ihlali, modül sınırı asimi veya katman ihlali iceren pull request'ler merge edilmeden once duzeltilmelidir. Bu disiplin olmadan en iyi diyagramlar bile zamanla erozyona ugrar.

Metrikler ve geri bildirim

Modül basina değişim sikligi, test coverage, cyclomatic complexity ve build sure metrikleri mimari sagligi gösterir. Ani complexity artisi veya test coverage dususu refactoring ihtiyacinin sinyalidir. Teknik liderlik bu metrikleri sprint review'da is degeri ile birlikte degerlendirmelidir.

Incident post-mortem'lerinde kok neden analizi mimari sınırları da kapsamali. Cross-modül veya cross-layer coupling iceren hatalar ADR veya mimari backlog'a donusturulmelidir. Tekrarlayan ihlaller otomatik lint kurallari ile onlenir.

Üretim ortaminda mimari disiplin

Mimari kararlar yalnizca tasarım dokumaninda kalmamali; CI pipeline, code review checklist ve otomatik analiz araclari ile gunluk geliştirme akisina gomulmelidir. Bağımlılık ihlali, modül sınırı asimi veya katman ihlali iceren pull request'ler merge edilmeden once duzeltilmelidir. Bu disiplin olmadan en iyi diyagramlar bile zamanla erozyona ugrar.

Metrikler ve geri bildirim

Modül basina değişim sikligi, test coverage, cyclomatic complexity ve build sure metrikleri mimari sagligi gösterir. Ani complexity artisi veya test coverage dususu refactoring ihtiyacinin sinyalidir. Teknik liderlik bu metrikleri sprint review'da is degeri ile birlikte degerlendirmelidir.

Incident post-mortem'lerinde kok neden analizi mimari sınırları da kapsamali. Cross-modül veya cross-layer coupling iceren hatalar ADR veya mimari backlog'a donusturulmelidir. Tekrarlayan ihlaller otomatik lint kurallari ile onlenir.