1. GİRİŞ

Modern yazılım sistemleri büyüdükçe iş gereksinimleri, terminoloji ve sorumluluklar tek bir modelde toplanamaz hale gelir. "Bounded Context" (sınırlı bağlam) kavramı, bir domain modelinin anlamının ve sorumluluklarının açık, tutarlı ve yönetilebilir bir sınır içinde tanımlanmasını sağlar. Bu yaklaşım, hem teknik mimari kararları hem de organizasyonel yapılandırmayı etkileyerek karmaşık sistemlerin sürdürülebilirliğini artırır.

Bu konu neden bugün önemli?

• Karmaşık mikroservis mimarilerinde domain sınırları net değilse hizmetler arasında kavramsal sürtüşme ve teknik borç hızla birikir.
• Çoklu ekip ve hızla değişen ürün gereksinimlerinde doğru context tanımları ekiplerin bağımsız olarak çalışmasını sağlar.
• Event driven, CQRS/ES, DDD gibi modern yaklaşımlar bounded context kavramını bir yapı taşı olarak kullanır.

Kimler için önemli?

• Yazılım mimarları ve teknik liderler
• Backend geliştiriciler ve platform mühendisleri
• Ürün yöneticileri ve domain uzmanları

Hangi problemleri çözüyor?

• Terimlerin farklı bağlamlarda değişik anlamlar taşıması (vocabulary drift)
• Servis sınırları ve ownership belirsizliği
• Cross‑team entegrasyon karmaşası ve coupling

2. KAVRAMSAL TEMELLER

2.1 Bounded Context nedir?

Bounded Context, bir domain modelinin tutarlı olduğu mantıksal sınırdır. Bu sınır içinde terimler, kurallar ve invariants netleşir; sözlük (ubiquitous language) bağlam içinde sabittir. Bounded Context, kod bazında bir modül, servis, takım veya deploy birimi olabilir.

2.2 Context Map — sınırların haritalanması

Context Map, sistemi oluşturan bounded context'lerin birbirleriyle nasıl ilişkilendiğini gösterir: conformist, anticorruption layer (ACL), shared kernel, customer‑supplier gibi modeller. Bu harita, entegrasyon stratejilerini ve sorumlulukları belgelemek için kullanılır.

2.3 Ubiquitous Language ve terminoloji

Her bounded context kendi ubiquitous language'ine sahiptir. Aynı kelime farklı bağlamlarda farklı anlamlara gelebilir; bu nedenle terimler açıkça tanımlanmalı ve domain uzmanlarıyla birlikte doğrulanmalıdır.

2.4 Bounded Context vs Microservice

Bounded Context ve microservice sıklıkla birbiriyle karıştırılır. Bounded Context bir modelleme kavramıdır; microservice, dağıtık mimari stilidir. İdeal olarak bir bounded context bir veya daha fazla microservice'e haritalanabilir; tersine microservice'ler bazen tek bir bounded context'i paylaşabilir. Önemli olan model sınırının kavramsal netliğidir, teknik deploy granülünden bağımsızdır.

3. NASIL ÇALIŞIR? — TEKNİK VE ORGANİZASYONEL MİMARİ

3.1 Context discovery: bağlamları nasıl bulursunuz?

Context discovery süreci tipik olarak şu adımları içerir:

1. Domain uzmanlarıyla workshop'lar ve event storming oturumları düzenleyin.
2. İş süreçlerini ve veri akışlarını belgeleyin; hangi terimlerin hangi anlamda kullanıldığını tespit edin.
3. Takım sorumluluklarını, deploy/pipeline sınırlarını ve veri ownership'lerini eşleştirin.
4. Context Map oluşturarak ilişkileri ve entegrasyon tiplerini (sync vs async, push vs pull) tanımlayın.

3.2 Entegrasyon stratejileri

Bounded context'ler arasındaki entegrasyon için yaygın stratejiler:

• Synchronous API (REST/gRPC): Doğrudan çağrılar; simple fakat tight coupling oluşturur ve latency sorunları doğurabilir.
• Asynchronous messaging (events, queues): Loose coupling sağlar; eventual consistency gerektirir.
• Anti‑Corruption Layer (ACL): Bir bağlamı diğerinin modelinden "izole" edecek adaptör katmanı; translation ve normalizasyon yapar.
• Shared Kernel: Küçük paylaşılan model parçası; dikkatle yönetilmelidir çünkü coupling getirir.

3.3 Anti‑Corruption Layer (ACL) detayları

ACL, dış bağlamdan gelen istekleri/mesajları iç modelinize uygun hale getiren bir çeviri katmanıdır. Temel sorumlulukları:

• Veri ve terim çevirisi (mapping)
• Validation ve policy uygulama
• Fail‑safe ve fallback stratejileri

3.4 Eventual consistency ve compensating transactions

Asenkron entegrasyon kullandığınızda bounded context'ler arasında tutarlılık anlık olmayabilir. Saga veya compensating transaction pattern'ları uzun süreli iş akışlarında tutarlılığı sağlamak için kullanılır. Tasarımda, hangi fluent işlemlerin strongly consistent kalması gerektiğine karar verilmeli ve cross‑context işlemler minimalize edilmelidir.

3.5 Data ownership ve replication

Hangi bağlamın hangi veriyi sahiplenip güncelleme hakkı olduğu açıkça tanımlanmalıdır. Read performansı için veri bazen başka bağlamlara replike edilebilir (denormalize). Bu replikasyonın nasıl güncel tutulacağı (event sourcing, change data capture, push events) açıkça belirlenmelidir.

4. GERÇEK DÜNYA KULLANIMLARI ve ÖRNEKLER

4.1 E‑ticaret: katalog, sipariş, ödeme bağlamları

E‑ticaret sistemlerinde katalog (ürün verisi), sipariş (order lifecycle) ve ödeme (payment processing) genellikle ayrı bounded context'lerdir. Örneğin "Price" terimi katalog bağlamında listelenen önerilen satış fiyatını ifade ederken, ödeme bağlamında final charge amount farklı kurallara göre hesaplanabilir. Bu ayrım yanlış yapılırsa fiyat tutarsızlıkları ve customer support maliyetleri artar.

4.2 Bankacılık: hesap, işlem, risk yönetimi

Finansal sistemlerde hesap yönetimi, ödeme işleme ve risk scoring farklı bounded context'lerdir. Risk bağlamı kendi modellerini kullanır ve ham transaction verisini farklı şekilde yorumlar; ACL katmanları ile veriler güvenli ve doğru biçimde dönüştürülür.

4.3 Sağlık sektörü: klinik, hasta yönetimi, faturalama

Sağlık yazılımlarında hasta verisi, klinik notlar ve faturalama mekanizmaları farklı semantic anlamlara sahiptir. Hasta kimliği ve gizlilik politikaları her bağlamda farklı iş kuralları gerektirebilir; bu yüzden context sınırları ve veri erişim kontrolleri dikkatle tasarlanmalıdır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Modüler ve anlaşılabilir modeller: bağlamların net olması karmaşıklığı azaltır.
• Takım bağımsızlığı: ekipler kendi bounded context'leri üzerinde daha özgür çalışır.
• Ubiquitous language ile iletişim hataları azalır; domain uzmanları ve geliştiriciler arasında ortak dil sağlanır.

Sınırlamalar

• Başlangıç maliyeti: doğru context discovery ve mapping için zaman ve uzmanlık gerekir.
• Entegrasyon karmaşıklığı: cross‑context işlemler ve veri replikasyonu karmaşıklaşabilir.
• Over‑modularization riski: gereksiz boundary'ler operasyonel yük ve latency artırabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Context discovery'yi event storming ile birlikte yapın; domain uzmanları, geliştiriciler ve ürün yöneticilerini dahil edin.
• Context Map'i canlı belge olarak tutun; entegrasyon değişikliklerinde güncelleyin.
• ACL kullanımı gerektiğinde ince, test edilebilir adapter'lar geliştirin; mapping kurallarını sürdürün.

Performans ve ölçeklenebilirlik

• Asenkron eventler ile read model replikasyonu kullanarak read yükünü dengeleyin.
• Hot path'leri tespit edin ve gerekirse context sınırlarını yeniden değerlendirin.

Güvenlik ve veri koruma

• Veri sahipliğini ve yetkilendirmeyi bounded context seviyesinde tanımlayın.
• PII ve hassas verileri yalnızca gerekli bağlamlarda saklayın; masking ve encryption kullanın.

Operasyonel pratikler

• CI/CD pipeline'larınızı bounded context sınırlarına göre yapılandırın; bağımsız deploy imkanı sağlayın.
• Metrikler: projection lag, cross‑context call latency, integration error rate gibi metrikleri izleyin.

8. SIK YAPILAN HATALAR

• Bağlamları iş süreçlerine göre değil, veritabanı tablolarına göre bölmek.
• Context Map'i yok saymak ve entegrasyon politikalarını belgelendirmemek.
• ACL yerine doğrudan model paylaşımı yapmak — zamanla coupling artar.
• Takım ownership'i tanımlamadan boundary'leri oluşturmak — sorumluluk bulanıklığı ortaya çıkar.

9. GELECEK TRENDLER

1. Domain‑aware tooling: Model discovery, semantic diff, ve context mapping araçları daha yaygın olacak.
2. AI destekli context discovery: Telemetry ve repository analizleri ile bounded context önerileri otomatikleşecek.
3. Event Mesh ve federated governance: Çoklu cluster ve vendor ortamlarında domain‑aware routing ve policy enforcement öne çıkacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Bounded Context'i nasıl hemen uygulamaya başlatırım?

   Önce kısa bir event storming ve terim keşfi yapın; hızlıca birkaç bounded context önerisi çıkarıp en kritik iş akışlarına göre önceliklendirin. Küçük adımlarla, bir veya iki context'te başlayın ve gözlemlere göre genişletin.

2. 2. Microservice ve bounded context eşleşmesi zorunlu mu?

   Hayır. İdealde her bounded context bir veya birkaç hizmete haritalanır; ancak kurumsal gerçeklikte bir microservice birden fazla context'i kapsayabilir. Önemli olan model tutarlığıdır.

3. 3. ACL yerine shared kernel kullanmalı mıyım?

   Sadece çok küçük ve stabil ortak kod/parçalar için shared kernel düşünülebilir. Shared kernel coupling getirir; ACL genelde daha güvenli ve esnek bir seçenektir.

4. 4. Context Map nasıl sürdürülür?

   Context Map'i ekiplerin yaşam döngüsüne entegre edin: mimari review'lar, onboarding belgeleri ve sprint planning sırasında güncelleyin. Otomatik dokümantasyon araçları ile codebase'den izler çıkarabilirsiniz.

5. 5. Veri replikasyonu için hangi teknik tercih edilmeli?

   Event sourcing veya CDC (Change Data Capture) güçlü seçeneklerdir. Hangi yöntemin seçileceği ekip yetkinliği, latency ve storage gereksinimlerine bağlıdır.

6. 6. Bounded Context tasarımında en kritik metrikler nelerdir?

   Cross‑context call latency, number of independent deploys, integration error rate, ownership clarity ve domain vocabulary concordance gibi metrikler önemlidir.

7. 7. Çok sayıda bounded context yönetimi zor mu?

   Evet, yönetimsel yük artar. Governance, discovery tooling, context map ve ekip organizasyonu ile bu yükü azaltabilirsiniz. Event mesh ve federation gibi teknolojiler de yardımcı olur.

8. 8. Legacy monolitten bounded context'e geçiş nasıl yapılır?

   Strangler Fig pattern ile adım adım taşıma en güvenli yaklaşımdır: bir fonksiyonelliği kesip yeni bounded context'e taşıyın, old endpoint'i yeni sistemle proxyleyin ve iteratif olarak ilerleyin.

Anahtar Kavramlar

Bounded Context

Modelin anlamının tutarlı olduğu sınırlı domain kapsamı.

Context Map

Context'ler arasındaki ilişki ve entegrasyon stratejilerini gösteren harita.

Anti‑Corruption Layer

Dış bağlamın modelini iç modele çeviren adaptör katmanı.

Shared Kernel

Birkaç bounded context arasında paylaşılan küçük model parçası.

Strangler Fig

Legacy sistemlerden yeni bounded context'lere kademeli geçiş stratejisi.

Öğrenme Yol Haritası

1. 0–1 ay: DDD temel kavramlarını, ubiquitous language ve bounded context tanımlarını öğrenin; küçük bir domain modelleyin.
2. 1–3 ay: Event storming ve context mapping oturumları yapın; ACL ve integration pattern'larını deneyin.
3. 3–6 ay: Strangler Fig ile legacy bölütleme, event driven replikasyon ve deployment bağımsızlığı üzerine pratik uygulamalar yapın.
4. 6–12 ay: Governance, event mesh, federated discovery ve AI destekli tooling ile bounded context yönetimini olgunlaştırın.