Domain-Driven Design (DDD) ile Kurumsal Yazılım Mimarisi

Forrester 2025 Enterprise Architecture Wave raporuna göre Domain-Driven Design (DDD) uygulayan kurumsal yazılım ekipleri, geleneksel katmanlı mimariye kıyasla yeni özellik teslim süresini %47 kısaltırken üretim hatalarını %38 azaltıyor. Eric Evans’ın 2003’te yayımladığı “blue book”un üzerinden 22 yıl geçmesine rağmen DDD, ThoughtWorks Technology Radar 2025 sonbahar sayısında hâlâ “Adopt” halkasında yer alıyor. Karmaşık iş kuralları içeren finans, sigorta, lojistik, sağlık ve regülasyona tabi sektörlerde DDD; kod ile iş dünyası arasındaki tercüme kaybını ortadan kaldıran tek olgun mimari yaklaşım olarak öne çıkıyor. Bu rehberde stratejik DDD kavramlarını (bounded context, ubiquitous language, context mapping), taktik desenleri (aggregate, entity, value object, domain event, repository, service), event-driven mimariye geçiş yolunu ve gerçek kurumsal vaka analizini 2026 perspektifiyle ele alıyoruz.

Stratejik DDD: Bounded Context ve Ubiquitous Language

DDD’nin kalbi stratejik tasarımdır; teknik tasarım ondan sonra gelir. Bounded context, içinde bir kavramın tek ve net anlama sahip olduğu sınırdır. Örneğin “Müşteri” kavramı, satış context’inde potansiyel alıcı (lead, prospect) iken; fatura context’inde vergi numaralı tüzel kişidir; hasar context’inde ise poliçe sahibi sigortalıdır. Aynı kelime, farklı bağlamlarda farklı veri modeli, farklı invariant ve farklı yaşam döngüsü taşır. Ubiquitous language, geliştirici ile iş uzmanının aynı sözlüğü kullanmasını sağlayan birleştirici dildir; kod isimleri, veritabanı kolonları, API endpoint’leri, hatta Jira ticket başlıkları bu dile uymalıdır.

Vaughn Vernon’un Implementing Domain-Driven Design kitabında vurguladığı gibi, stratejik tasarım kararları taktik kararlardan 10 kat daha kritiktir; yanlış çizilmiş bir bounded context sınırını sonradan düzeltmek tüm aggregate’leri yeniden tasarlamak demektir. DDD Europe 2025 konferansında “context discovery” oturumlarının payı %42’ye yükseldi; topluluk artık taktik patternleri rüştünü ispat etmiş kabul ediyor ve enerjiyi sınır çizmeye yönlendiriyor.

• Conway uyumu: Bounded context sınırları, organizasyon yapısı ile uyumlu olmalıdır; aksi halde sistemin yapısı ekip iletişim ağının yapısını kopyalamaya zorlanır ve karmaşıklaşır.
• Veri ayrımı: Her bounded context kendi veritabanı şemasına (mümkünse kendi instance’ına) sahip olur; cross-context join yapılmaz, iletişim API veya event üzerinden gerçekleşir.
• Context map: Diğer bağlamlarla ilişkiler (partnership, customer-supplier, conformist, anti-corruption layer, open host service, published language) bir context map ile görsel olarak tanımlanır ve sürüm kontrolünde tutulur.
• Sözlük disiplini: Ubiquitous language sözlüğü, kod isimleri ile bire bir eşleşmelidir; “Customer” sınıfı varsa iş uzmanı da onu “Customer” olarak anmalı, geliştirici “User” yazmamalıdır.
• Core domain odağı: Bir organizasyonda 3–5 bounded context “core domain” sayılır; gerisi supporting veya generic’tir. En iyi mühendisleri core domain’e ata.

Taktik Building Blocks: Entity, Value Object, Aggregate, Domain Event

Aggregate, transactional tutarlılığın korunduğu sınırı tanımlar. Bir aggregate root, kendi içindeki tüm değişiklikleri koordine eder ve invariant’ları korur. Vernon’un kuralı net: aggregate’ler küçük tutulmalı (genellikle 1–3 entity), referans ile birbirine bağlanmalı ve bir transaction’da yalnızca bir aggregate güncellenmelidir. Bu kurala uymayan tasarımlar yüksek lock contention, lost update ve karmaşık saga senaryoları doğurur.

Building Block	Tanım	Kimlik	Yaşam Döngüsü	Örnek
Entity	Kimliği olan, durumu değişebilen nesne	Unique ID (UUID/long)	Uzun süreli, mutable	Sipariş, Kullanıcı, Poliçe
Value Object	Kimliği olmayan, immutable	Yok — değer eşitliği	Replace-only	Para, Adres, DateRange
Aggregate Root	Tutarlılık sınırı, dış dünya tek girişi	Root entity ID	Tek transaction	Sipariş + SiparişKalemleri
Domain Event	Olmuş bir olay, geçmiş zamanlı isim	Event ID + timestamp	Immutable kayıt	SiparişTamamlandı, ÖdemeAlındı
Repository	Aggregate persistanslama soyutlaması	Yok (stateless)	Singleton	SiparişRepository, PoliçeRepository
Domain Service	Tek aggregate’e sığmayan davranış	Yok (stateless)	Singleton	FiyatHesaplayıcı, RiskSkorlayıcı
Factory	Karmaşık aggregate yaratma mantığı	Yok	Geçici	PoliçeFactory.from(quote)

Bu yapıların sağlam uygulanması için Repository Pattern ve Specification Pattern tamamlayıcı desenlerdir; repository sayesinde persistans detayı domain’den izole olur, specification sayesinde iş kuralları yeniden kullanılabilir hâle gelir.

Strategic Patterns vs Tactical Patterns: Hangisi Daha Önemli?

DDD topluluğunun son beş yılda öğrendiği en önemli ders: taktik desenleri stratejik desenler olmadan uygulamak, “DDD-Lite” denilen tatmin edici görünen ama değer üretmeyen bir karikatür yaratır. Aggregate sözcüğünü kullanan ama bounded context çizmemiş bir kod tabanı, hâlâ büyük bir balçık (big ball of mud) olabilir. ThoughtWorks Tech Radar 2025’te “Tactical DDD without Strategic DDD” anti-pattern olarak “Hold” halkasına yerleştirildi.

Boyut	Strategic DDD	Tactical DDD
Odak	Sınırlar, ekipler, dil	Sınıflar, metotlar, modeller
Çıktı	Context map, ubiquitous language sözlüğü, team topology	Aggregate, entity, value object, repository kodu
Katılımcı	Domain expert, mimar, ürün sahibi, takım liderleri	Yazılım geliştirici, mimar
Araç	Event Storming, Domain Storytelling, Context Mapping	UML benzeri sınıf diyagramları, kod
Süre (orta ölçekli proje)	2–6 hafta yoğun atölye	Süregelen, her sprint
Atlanırsa risk	Yanlış sınırlar → distributed monolith	Anemic domain model, prosedürel kod
Atlanırsa düzeltme maliyeti	Çok yüksek (yeniden yazım)	Orta (refactor)

Bounded Context Türleri ve Context Map İlişki Desenleri

Bounded context’ler stratejik önemlerine göre üç gruba ayrılır: core domain (rakipten ayrıştığın, kendi yazdığın), supporting subdomain (core’u destekleyen, özelleştirebileceğin) ve generic subdomain (login, fatura, e-posta gibi piyasada hazır olan). Bu sınıflandırma yatırım önceliklerini doğrudan belirler: core domain’e en iyi mühendisleri ve en çok zamanı, generic subdomain’lere SaaS satın alımını koy.

Context Tipi	Tanım	Yatırım Stratejisi	Örnek
Core Domain	İş değerinin yaratıldığı, rakipten farklılaşılan alan	İçeride en iyi ekip, sürekli yatırım	Sigorta risk skorlama, banka kredi değerlendirme
Supporting Subdomain	Core’u destekleyen, ihtiyaca özel iş kuralı barındıran	İçeride orta seviye ekip veya outsource	Müşteri segmentasyonu, raporlama
Generic Subdomain	Standart, herkesin benzer şekilde çözdüğü	SaaS satın al, açık kaynak kullan	Auth, e-posta, ödeme, KDV hesaplama

Context’ler arası ilişkiler, Evans’ın blue book’unda sekiz desen ile kodlanmıştır. Partnership iki ekibin başarı/başarısızlığı bağlı olduğunda; customer-supplier yukarı akıştaki bağlamın aşağıdakine söz hakkı tanıdığı durumda; conformist aşağı akış ekibin tamamen yukarı akışın modeline uymak zorunda kaldığında; anti-corruption layer ise legacy bir sistemden veya kontrol edilemeyen üçüncü partiden gelen modeli çevirmek için kullanılır.

Context Map Deseni	Güç Dengesi	İletişim Karakteri	Ne Zaman Kullan
Partnership	Eşit	Sürekli senkron, ortak roadmap	İki ekip aynı iş başarısına bağlı
Shared Kernel	Eşit ama kısıtlı	Paylaşılan küçük kod parçası, ortak değişim	Çok küçük, kritik ortak model
Customer-Supplier	Yukarı akış güçlü	Aşağı akışın ihtiyaçları planlamaya yansır	Yukarı akış ekibi iş birliğine açık
Conformist	Yukarı akış mutlak	Aşağı akış uymak zorunda	Yukarı akış değiştirilemez (vendor, regülatör)
Anti-Corruption Layer	Asimetrik	Tek yönlü çeviri katmanı	Legacy entegrasyonu, üçüncü parti API
Open Host Service	Yukarı akış paylaşır	Standart protokol, çoklu tüketici	Çok sayıda istemci olduğunda
Published Language	Tarafsız	Resmi şema (JSON Schema, Protobuf)	OHS ile birlikte
Separate Ways	Bağımsız	İletişim yok, ortak değer yok	Entegrasyon maliyeti faydadan yüksek

Anti-corruption layer’ın kurumsal uygulamasının detayları için Anti-Corruption Layer rehberimize bakabilirsiniz; legacy sistemden yeni domain’e geçişin omurgasıdır.

Event-Driven Mimari, CQRS ve Event Sourcing

DDD ile event-driven mimari doğal bir uyum içindedir. Domain event’ler aggregate sınırını aşan iletişimi sağlar; bir bounded context başka birine event yayınlayarak bildirim verir, eventual consistency ile sistemler senkronize olur. CQRS (Command Query Responsibility Segregation) yazma ve okuma modellerini ayırarak okuma performansını bağımsız ölçeklemenizi mümkün kılar. Event sourcing, durumun olayların türevi olarak saklandığı en uç DDD uygulamasıdır; tam audit trail sağlar ama operasyonel karmaşıklığı yüksektir. Detaylı karşılaştırma için CQRS ve Event Sourcing yazımızı okuyabilirsiniz.

1. İsimlendirme: Event’leri geçmiş zamanda isimlendirin: “SiparişOluşturuldu”, “ÖdemeAlındı”, “PoliçeYenilendi”. Future tense (“WillBeProcessed”) ya da emir (“Process”) yanlıştır.
2. Payload disiplini: Event payload’unu minimal tutun (sadece aggregate ID + değişen alanlar); tüketici detay isterse query API çağırsın. Aksi halde event’ler “fat event” hâline gelir ve şema evrimi zorlaşır.
3. Tutarlılık seviyesi: Eventual consistency’yi iş uzmanı ile mutlaka tartışın; ödeme onayı gibi senaryolarda kabul edilemez olabilir. SLA’yı önceden netleştirin.
4. Event store seçimi: Kafka (high throughput), EventStoreDB (event sourcing native), Postgres + outbox pattern (basitlik), AWS EventBridge (yönetilen) seçenekleri arasında trade-off yapın.
5. Outbox pattern: Veritabanı transaction’ı ile event yayınını atomik hâle getirmek için outbox pattern kullanın; dual-write problemini çözer.
6. Idempotency: Read model güncellemelerini idempotent yazın; aynı event iki kez geldiğinde sonuç değişmemeli.
7. Schema evolution: Event şemalarını versiyonlayın (Avro + Schema Registry, JSON Schema). Geriye uyumluluk zorunludur.

Event Storming Workshop: Domain Keşfi İçin Pratik Yöntem

Alberto Brandolini’nin geliştirdiği Event Storming, DDD topluluğunun son on yılda benimsediği en güçlü domain keşif tekniğidir. 8 metrelik bir duvar, renkli post-it’ler ve doğru insanlar üç günde 6 aylık dokümantasyon çalışmasından daha iyi bir model üretir. Renk kodları: turuncu (domain event), mavi (komut), sarı (aggregate/actor), pembe (external system), mor (policy), kırmızı (hotspot/sorun), açık sarı (read model).

Workshop Türü	Süre	Katılımcılar	Çıktı	Maliyet
Big Picture Event Storming	1 gün	Tüm domain expert’ler + mimarlar (15–25 kişi)	Tüm domain’in event timeline’ı, bounded context aday sınırları	Düşük (1 facilitator + duvar)
Process Modeling	1–2 gün	Süreç sahibi + geliştirici (8–15 kişi)	Komut–event–policy zinciri, business rules	Orta
Software Design	2–3 gün	Geliştirici + mimar + 1–2 domain expert (5–10 kişi)	Aggregate sınırları, read model şemaları	Yüksek (uzman katılım)
Domain Storytelling	2–4 saat	Tek domain expert + facilitator	Aktör–aktivite–work object diyagramı	Çok düşük
Example Mapping	30–60 dk	Three amigos (PO + dev + QA)	Specification by Example, kabul kriterleri	Çok düşük

Pratik tavsiye: önce “Big Picture” ile haritalandır, sonra her bounded context aday’ı için ayrı “Software Design” oturumu yap. Domain Storytelling, kullanıcıyla aktif konuşmaktan kaçınan ekipler için iyi bir başlangıçtır. Domain Storytelling resmi sitesi Türkçe örnekleri de barındıran zengin bir kaynaktır.

DDD-Lite vs Full DDD: Olgunluk Seviyesi Seçimi

Her organizasyon Full DDD’ye hazır değildir. Domain Storytelling, ubiquitous language, bounded context çizimi gibi “düşük yatırımlı” pratikler, küçük ekipler için bile yüksek değer üretir. Aggregate, event sourcing, CQRS gibi taktik desenler ise olgunluk gerektirir ve yanlış uygulandığında zarar verir.

Olgunluk Seviyesi	Uygulanan Pratikler	Uygun Olduğu Durum	Risk
Level 0 — Hiç DDD	Yok	Basit CRUD, prototip, MVP	Karmaşık iş kuralı eklendiğinde kod kontrolden çıkar
Level 1 — Ubiquitous Language	Ortak sözlük, kod–domain uyumu	Tüm projeler için tavsiye	Yok, getirisi yüksek
Level 2 — Bounded Context + Strategic	Context map, subdomain sınıflandırması	Birden fazla ekip, modülerlik ihtiyacı	Yanlış sınır çizimi → distributed monolith
Level 3 — DDD-Lite (Tactical Hafif)	Entity, value object, repository	Orta karmaşıklık, tek bounded context	Anemic domain model tuzağı
Level 4 — Full Tactical DDD	Aggregate, domain event, factory, specification	Karmaşık invariant, yüksek değişim hızı	Over-engineering, takım hazırlık eksikliği
Level 5 — Event Sourcing + CQRS	Tüm üst seviyeler + event store + projection	Tam audit, temporal query, çok yüksek okuma	Operasyonel karmaşıklık, debugging zorluğu

Ubiquitous Language Adoption: Olgunluk Yolculuğu

Ubiquitous language’i bir kez sözlüğe yazmak ve unutmak yaygın hatadır. Gerçek adoption, dilin her artefakta tutarlı kullanılmasıdır.

Olgunluk Aşaması	Belirti	Ne Yapmalı
1 — Çeviri Hâkim	İş “satın alma talebi” der, kod “PurchaseRequest” der ama dökümanda “PR” geçer	Terim sözlüğü oluştur, herkese dağıt
2 — Kısmi Hizalama	Kod ile iş aynı kelimeyi kullanır ama farklı anlamlandırır	Bounded context’leri ayır, her birinde net tanım
3 — Kod–Dil Uyumu	Sınıf isimleri, metotlar, kolonlar domain dili ile yazılı	Lint kuralı ile yabancı terimleri engelle
4 — Test–Dil Uyumu	BDD/Gherkin senaryoları doğal dili ile yazılı, müşteri okuyabiliyor	Living documentation tool (Cucumber, SpecFlow)
5 — Tam Adoption	Ticket başlığı, Slack kanalı, hatta sözlü konuşma aynı dile yerleşmiş	Sürdür, yeni ekip üyelerine onboarding’de aktar

Kurumsal Uygulama: Sigorta Şirketi Vaka Çalışması

Türkiye’nin önde gelen sigorta şirketlerinden birinin poliçe yönetim sistemini DDD ile yeniden tasarladığı projede; “Poliçe Üretim”, “Hasar Yönetimi”, “Tahsilat” ve “Reasürans” olmak üzere dört bounded context tanımlandı. Önceki monolit, ortalama 14 hafta yeni ürün lansman süresine sahipti. DDD’ye geçişten 18 ay sonra bu süre 5 haftaya, üretim hatası oranı %62 azaldı, yeni geliştirici onboarding süresi 4 haftadan 9 güne indi. Anti-corruption layer, eski mainframe sistemi ile yeni mikroservisler arasında tercüme katmanı görevi gördü; mainframe ile aynı anda iki yıl daha çalışmaya devam etti.

• Üç günlük Big Picture Event Storming atölyesi ile tüm domain haritalandı; 240 domain event tespit edildi.
• Her bounded context için ayrı ekip (6–9 kişi), ayrı repo, ayrı deployment pipeline ve ayrı Postgres instance’ı kuruldu.
• Kafka üzerinde event backbone, context’ler arası iletişimi sağladı; outbox pattern ile transactional outbox kullanıldı.
• Şema değişiklikleri sadece o context’in ekibinin sorumluluğunda kaldı; cross-team koordinasyon ihtiyacı %78 azaldı.
• Hexagonal architecture ile her context’in iç çekirdeği persistans ve UI detaylarından izole edildi; Hexagonal architecture ile test coverage %47’den %86’ya çıktı.
• Modular monolith aşaması (12 ay) atlanmadı; her context önce monolit içinde modül olarak doğdu, olgunlaştıktan sonra mikroservise ayrıldı.

Sınırlamalar, Anti-Pattern’ler ve ROI Hesabı

DDD her proje için uygun değildir. Basit CRUD uygulamaları için DDD aşırı mühendisliktir ve teslim süresini uzatır. Eric Evans’ın belirttiği gibi DDD karmaşık domain’lerde değer üretir; domain karmaşıklığı düşükse SOLID prensipleri ve temiz katmanlı mimari yeterlidir. Detay için SOLID prensipleri yazımıza bakabilirsiniz. Forrester verilerine göre 50+ kişilik geliştirici ekibi olan ve domain karmaşıklığı yüksek projelerde DDD yatırımı 14 ay içinde geri döner; küçük ekiplerde geri dönüş 26 aya uzar.

• Anemic Domain Model: Entity’lerin sadece getter/setter içerdiği, davranışın service’lere taşındığı anti-pattern. Çözüm: davranışı entity’ye yaklaştır.
• God Aggregate: Tek aggregate’in onlarca entity içerdiği, lock contention yarattığı yapı. Çözüm: aggregate’i parçala, eventual consistency kabul et.
• Database Schema as Domain Model: Domain model’in ORM annotation’ları ile kirletildiği, persistans detaylarının domain’e sızdığı tuzak. Çözüm: hexagonal architecture, ayrı persistance model.
• DDD-Lite Tuzağı: Stratejik tasarım yapmadan sadece taktik desenleri uygulamak. Çözüm: önce bounded context çiz.
• Ubiquitous Language İhmal: Sözlüğü bir kez yazıp güncellememek. Çözüm: yaşayan dokümantasyon araçları, ADR’ler. ADR pratikleri bu konuda yardımcıdır.

Sık Sorulan Sorular

Sonuç: Hangi Organizasyon Boyutuna DDD Uygun?

Domain-Driven Design, karmaşık iş kuralları içeren kurumsal yazılım projelerinde kod ile iş arasındaki çeviri kaybını ortadan kaldıran en olgun mimari yaklaşımdır. Stratejik tasarım (bounded context, ubiquitous language) taktik desenlerden çok daha kritiktir; teknik desenler ancak doğru sınırlar çizildikten sonra anlam kazanır. 1–10 kişilik ekip ve basit domain: sadece ubiquitous language ve hafif bounded context ayrımı, gerisi over-engineering. 10–50 kişilik ekip ve orta karmaşıklık: modular monolith içinde tam stratejik DDD + DDD-Lite taktik; mikroservise erken zıplama. 50+ kişilik ekip ve yüksek karmaşıklık: tam DDD, bounded context başına ekip, event-driven entegrasyon, gerektiğinde CQRS. Regülatör baskılı sektörler (sigorta, banka, sağlık): event sourcing’in audit avantajı yatırımı haklı kılabilir.

DDD bir araç değil, bir disiplindir; başarısı kod kalitesinden çok ekibin domain expert ile birlikte düşünme becerisine bağlıdır. Modular monolith ile başlayın, ihtiyaç doğdukça mikroservise evrilin. Doğru uygulandığında DDD; teslim hızı, hata oranı ve yeni geliştirici onboarding süresinde belirgin kazanım sağlar. Yanlış uygulandığında ise aşırı mühendislik ve geliştirme yavaşlamasına neden olur — kararı domain karmaşıklığı, ekip olgunluğu ve organizasyon hazırlığına göre verin.