Domain-Driven Design (DDD) benimseyen kurumlar yazılım projelerinde %42 daha az teknik borç ve %58 daha hızlı feature delivery raporlamaktadır. ThoughtWorks Technology Radar Vol. 31 DDD’yi “Adopt” kategorisinde listeler ve özellikle mikroservislere geçiş yapan kurumların %78’inin bounded context tanımıyla başladığını belgeler. Yanlış uygulama (anemic domain model, yanlış aggregate sınırları) ise distributed monolith’e ve yıllık 800.000-2,5 milyon USD’lik rework maliyetine yol açar.
Bu rehberde Domain-Driven Design’ı, bounded context ve aggregate pratiklerini kurumsal projeler için detaylı inceliyoruz:
- DDD’nin stratejik ve taktiksel desenleri
- Bounded context tanımı ve context map türleri
- Aggregate, entity, value object, domain event mimarisi
- Ubiquitous language ve event storming workshop’ları
- Mikroservis sınırlarının doğru çizilmesi
- CQRS, Event Sourcing ile DDD entegrasyonu
Domain-Driven Design Nedir ve Neden Kritik?
Domain-Driven Design, Eric Evans’ın 2003’te yayınladığı “Domain-Driven Design: Tackling Complexity in the Heart of Software” kitabıyla başlayan, karmaşık yazılım sistemlerinin business domain’i merkez alarak tasarlanmasını savunan bir yaklaşımdır. DDD; iş paydaşları ile geliştiriciler arasındaki bilgi uçurumunu kapatır ve “ubiquitous language” (ortak dil) ile iletişim zenginleşir.
DDD’nin sağladığı kurumsal avantajlar:
- Domain alignment: Yazılım yapısı iş domain’iyle 1:1 eşleşir
- Mikroservis sınırı netliği: Bounded context’ler servis sınırlarını verir
- Domain expert dahil olma: Event storming ile iş paydaşları aktif
- Karmaşıklık yönetimi: Subdomain ayrımı ile karmaşıklık parçalanır
- Test edilebilirlik: Pure domain logic %85+ unit test coverage
- Refactor kolaylığı: Anti-corruption layer ile değişim izolasyonu
Stratejik DDD: Subdomain ve Bounded Context
Stratejik DDD, sistemin yüksek seviye yapısını tanımlayan pattern’leri içerir. Martin Fowler bounded context’i DDD’nin en önemli stratejik konsepti olarak nitelendirir.
| Subdomain Türü | Açıklama | Örnek (E-ticaret) | Yatırım Stratejisi |
|---|---|---|---|
| Core Domain | Şirketin rekabet avantajı | Öneri motoru, pricing | En iyi geliştiriciler, custom build |
| Supporting Subdomain | Gerekli ama ayrıştırıcı değil | Sipariş yönetimi, sepet | Custom build, daha az yatırım |
| Generic Subdomain | Standart, hazır çözüm var | Kimlik doğrulama, ödeme | SaaS/ürün satın al |
Bounded Context: Sistemin Kalbi
Bounded context, belirli bir domain modelinin geçerli olduğu açık bir sınırı tanımlar. Aynı kavram (örn. “Müşteri”) farklı bounded context’lerde farklı veri ve davranışa sahip olabilir.
Bounded context’in temel özellikleri:
- Açık sınır: Modelin başladığı ve bittiği yer net
- Kendi ubiquitous language’ı: Aynı terim farklı anlamlar taşıyabilir
- Bağımsız persistence: Genelde ayrı veritabanı veya şema
- Tek sahip ekip: Conway’s Law’a uyumlu
- Açık tanımlı API: Diğer context’lerle entegrasyon kontrollü
- Bağımsız deployment: Mikroservis-ready
Context Mapping: Bounded Context’ler Arası İlişkiler
Gerçek sistemlerde 5-50 bounded context bulunur ve bunlar arasında çeşitli ilişki tipleri vardır. Context map bu ilişkileri görselleştirir.
| İlişki Türü | Açıklama | Kullanım Senaryosu | İmplementasyon Pattern |
|---|---|---|---|
| Partnership | Karşılıklı bağımlılık, ortak hedef | İki ekip de değişikliği koordine eder | Shared planning, joint ownership |
| Shared Kernel | Ortak küçük kod parçası | İki context paylaşımlı tip kullanır | Shared library, monorepo |
| Customer-Supplier | Upstream/downstream hiyerarşi | Downstream ihtiyaçları planlamayı etkiler | Backwards compatibility |
| Conformist | Downstream upstream’i benimser | Üçüncü taraf API entegrasyonu | Direct adoption |
| Anti-Corruption Layer (ACL) | Upstream’i kendi modelimize çevir | Legacy entegrasyon, dış SaaS | Translator, adapter pattern |
| Open Host Service | Açık API ile çoklu tüketici | Platform servisleri | REST/GraphQL public API |
| Published Language | Standart şema (örn. ISO 20022) | Sektörel standartlar | JSON Schema, Protocol Buffers |
| Separate Ways | Entegrasyon değer üretmiyor | İlgisiz domain’ler | Bağımsız sistemler |
Taktiksel DDD: Aggregate, Entity, Value Object
Taktiksel DDD, bounded context içindeki kod yapısını şekillendirir. Aggregate’lar tutarlılık sınırlarını, entity’ler kimlikli nesneleri, value object’ler kimliksiz değer nesnelerini tanımlar.
| Pattern | Tanım | Örnek | Eşitlik Kriteri |
|---|---|---|---|
| Entity | Kimliği olan, değişebilen nesne | Customer, Order, Invoice | ID karşılaştırması |
| Value Object | Kimliksiz, immutable değer | Money, Address, DateRange | Tüm field karşılaştırması |
| Aggregate | Tutarlılık sınırı, root + child’lar | Order + OrderLines | Aggregate Root ID |
| Domain Service | Domain logic, entity’ye ait değil | PricingService, TaxCalculator | Stateless |
| Domain Event | Domain’de gerçekleşen önemli olay | OrderPlaced, PaymentReceived | Immutable fact |
| Repository | Aggregate persistence soyutlaması | OrderRepository | Collection benzeri API |
| Factory | Karmaşık aggregate oluşturma | OrderFactory | Encapsulated construction |
Aggregate Tasarımı: Doğru Sınırı Çizmek
Aggregate sınırlarının doğru çizilmesi DDD’nin en zorlu kısmıdır. Vaughn Vernon’un “Effective Aggregate Design” makaleleri (2011) aggregate tasarımı için 4 altın kural önerir.
- Aggregate root içinde gerçek invariant’ları koru: İş kuralı zorunluluğu olan veriyi aynı aggregate’ta tut
- Aggregate’ları küçük tasarla: Büyük aggregate’lar performans ve concurrency sorunlarına yol açar
- Diğer aggregate’lara reference ile başvur: Kompozisyon değil, sadece ID referansı
- Aggregate boundary’leri eventual consistency ile bağla: Domain event’ler ile asenkron iletişim
Bir e-ticaret örneğinde:
- Order Aggregate: Order (root) + OrderLines + ShippingAddress (VO)
- Product Aggregate: Product (root) + Variants + Pricing
- Customer Aggregate: Customer (root) + Addresses (VO) + ContactPreferences
- Order → Product referansı: ProductId, bütün Product değil
- Tek transaction = tek aggregate: Order ve Inventory ayrı tx’lerde günceller
Ubiquitous Language ve Event Storming
Ubiquitous language, domain expert’lerle geliştiricilerin ortak terminoloji kullanmasıdır. Event Storming, Alberto Brandolini’nin 2013’te tanıttığı workshop tekniğidir. 3-6 saatlik bir oturumda domain event’leri, command’leri ve aggregate’ları haritalandırır.
| Event Storming Aşaması | Süre | Çıktı | Sticky Note Rengi |
|---|---|---|---|
| Big Picture Exploration | 1-2 saat | Tüm domain event akışı | Turuncu (event) |
| Process Modeling | 2-3 saat | Aktör, command, policy | Sarı (actor), mavi (command) |
| Software Design Level | 3-6 saat | Aggregate, read model, hotspot | Pembe (aggregate), yeşil (read model) |
| Bounded Context Discovery | 1-2 saat | Bounded context sınırları | Mor (BC sınırı) |
| Context Mapping | 2-3 saat | Context map, ilişki tipleri | Beyaz (ilişki çizgisi) |
DDD ve Mikroservis Sınırları
Mikroservis mimarisinin en zor kararı servis sınırlarının çizilmesidir. ThoughtWorks 2024 raporu mikroservis projelerinin %62’sinin bounded context analizi olmadan başlatılması nedeniyle distributed monolith’e dönüştüğünü belgeler.
- 1 Bounded Context = 1 Mikroservis: Default başlangıç noktası
- 1 BC = N Mikroservis: Performans gerektiğinde sub-servisler
- N BC = 1 Modüler Monolit: Erken aşamada karmaşıklığı kontrol
- Database per service: Her servis kendi DB’sini sahiplenir
- API Gateway pattern: Cross-context koordinasyon
- Saga pattern: Cross-aggregate transaction yönetimi
CQRS ve Event Sourcing ile DDD
CQRS (Command Query Responsibility Segregation) ve Event Sourcing, DDD ile sıklıkla birlikte kullanılan pattern’lerdir. Read ve write modellerin ayrılması karmaşık domain’lerde okuma performansını artırır.
| Pattern | Yararı | Karmaşıklık | Önerilen Senaryo |
|---|---|---|---|
| CRUD | Basit, hızlı | Düşük | Basit domain’ler |
| DDD (Rich Domain) | İş kuralı encapsulation | Orta | Orta-karmaşık domain |
| CQRS | Read/Write ölçeklenmesi | Yüksek | Asimetrik R/W oranı |
| Event Sourcing | Tam audit, temporal query | Çok yüksek | Finansal, regülatör domain |
| CQRS + ES | Maksimum esneklik | Maks | Karmaşık + audit zorunlu |
DDD Uygulama Adımları
DDD’nin kurumsal projeye entegrasyonu fazlı bir süreçtir. 6-12 aylık bir geçiş tipiktir.
- Domain expert keşfi: İş paydaşlarıyla 1:1 görüşmeler, domain haritalama (2-3 hafta)
- Big picture event storming: Tüm domain’in ana akışlarını ortaya çıkarma (1-2 gün workshop)
- Subdomain ayrımı: Core, supporting, generic subdomain’leri tanımlama (1 hafta)
- Bounded context tanımı: Her subdomain için BC sınırları, ubiquitous language (2-3 hafta)
- Context map çizimi: BC’ler arası ilişki tipleri (1 hafta)
- Aggregate design: İlk core context için aggregate’lar (2-4 hafta)
- Implementation: Domain layer kod, tactical patterns (8-16 hafta per context)
- Anti-corruption layer: Legacy sistem entegrasyonu (BC başına 2-3 hafta)
- Refinement döngüsü: Bireysel context’lerin sürekli iyileştirilmesi (sürekli)
Mikroservis mimari geçiş rehberimizde detayları bulabilirsiniz. Hexagonal architecture yazımız DDD’nin teknik karşılığıdır.
DDD Yaygın Anti-Pattern’leri
DDD uygulamasının yanlış yorumlanması anti-pattern’lere yol açar. Martin Fowler’ın “Anemic Domain Model” makalesi en yaygın hatayı tanımlar.
- Anemic Domain Model: Entity’ler sadece getter/setter’a sahip, mantık service’lerde
- God Aggregate: Tek aggregate tüm bounded context’i içeriyor
- Shared Database: Birden fazla BC aynı DB tablosuna yazıyor
- Generic Domain pattern overuse: Generic subdomain için custom build
- Premature DDD: Basit CRUD domain için DDD overengineering
- Missing Ubiquitous Language: Geliştiriciler ve iş paydaşları farklı terimler kullanır
- Big Aggregate, Big Transaction: Tek transaction büyük aggregate’larla performans sorunu
Kurumsal DDD Dönüşümünde Karşılaşılan Tipik Sorunlar
DDD adopsiyonu teknik mimari kararlarından daha fazlasını gerektirir; iş paydaşı dahil olma, takım yapısı ve süreç olgunluğu kritiktir. Danışmanlık projelerinde gözlemlenen örüntüler, DDD geçişlerinin %37’sinin ilk yıl içinde anemic model’e geri döndüğünü göstermektedir. Tipik sorunlar:
- Domain expert eksikliği: İş paydaşları workshop’lara katılamıyor, ubiquitous language oluşmuyor
- Aggregate sınırı yanlış: Çok büyük aggregate’lar performans sorunu, çok küçük aggregate’lar invariant ihlali
- Ekip yapısı Conway uyumsuz: Bounded context ekip sınırlarıyla örtüşmüyor
- Legacy entegrasyon kaotik: Anti-corruption layer kurulmadan legacy modeli her yere sızıyor
- Premature mikroservisleştirme: BC’ler olgunlaşmadan distributed sisteme geçiş
- Event Storming workshop atlandı: Geliştiriciler kendi başlarına BC çiziyor, domain expertise eksik
Sık Sorulan Sorular
DDD her proje için uygun mu?
DDD karmaşık business domain’leri olan projeler için optimal seçimdir. Basit CRUD uygulamaları, prototype’lar ve domain logic’in minimum olduğu sistemler (örn. content management) için DDD overengineering sayılır. Genelde 3+ ay süreli, 5+ kişilik ekipler ve domain expert dahil olabilen projelerde DDD net değer üretir. Banka, sigorta, sağlık, lojistik gibi karmaşık iş kuralları olan sektörler ideal kullanım alanlarıdır.
Bounded context ve mikroservis aynı şey mi?
Hayır. Bounded context bir stratejik DDD konseptidir; mikroservis ise bir deployment ve dağıtım yaklaşımıdır. Bir bounded context tek bir mikroservise, birden fazla mikroservise veya modüler monolit içinde bir modüle karşılık gelebilir. Pratikte, başlangıç noktası “1 BC = 1 mikroservis” yaklaşımıdır ancak performans, sahiplik veya teknik gereksinimler ayrı servislere bölünmeyi gerektirebilir. Tersi de mümkündür: yeni proje “1 modüler monolit içinde N BC” şeklinde başlayıp olgunlaştıkça mikroservislere bölünebilir.
Event Storming workshop’unu kim moderatör etmeli?
Event Storming için ideal moderatör DDD deneyimi olan, domain knowledge’a sahip ve facilitator yetkinliği olan bir mimarttır. İlk workshop’larda dışarıdan deneyimli bir DDD danışmanı ile çalışmak öğrenme eğrisini hızlandırır (günlük 1.500-4.000 USD danışmanlık ücreti tipik). Workshop’a 5-15 katılımcı (1-2 domain expert, 3-8 geliştirici, 1-2 ürün yöneticisi, 1 mimar) optimal sayıdır. Süre 4-8 saat, fiziksel veya Miro/MURAL gibi sanal whiteboard araçlarıyla yapılır.
Aggregate boyutu nasıl belirlenir?
Aggregate boyutu için Vaughn Vernon’un altın kuralı: “design small aggregates”. İdeal aggregate 1-5 entity ve 5-15 method içerir. Aggregate’ın koruması gereken invariant’lar varsa (örn. Order toplam tutarı = OrderLine’ların toplamı) bu invariant’a katılan tüm veriler aynı aggregate’ta olmalıdır. İnvariant zorunluluğu olmayan ilişkiler ID reference ile bağlanmalı, eventual consistency kabul edilmelidir. Concurrency conflict’ler aggregate’ı küçültme sinyalidir.
Modüler monolit ve mikroservis arasında DDD ile nasıl seçim yaparım?
Yeni projeler için modüler monolit DDD’nin başlangıç noktası olarak önerilir. Bounded context’ler modül sınırlarıyla net çizilir ve operasyonel karmaşıklık (distributed transaction, network failure, observability) sonraya bırakılır. Şu durumlarda mikroservise geçilmelidir: (1) ekipler 8+ kişi ve bağımsız deploy gerekiyorsa, (2) servis bazında farklı scaling profili varsa, (3) farklı teknoloji stack gerekiyorsa, (4) regülatör izolasyon zorunluluğu varsa. Martin Fowler “Monolith First” yaklaşımını DDD ile birlikte savunur.
Sonuç
Domain-Driven Design, karmaşık kurumsal yazılım projelerinde 2026 itibarıyla kanıtlanmış bir mimari yaklaşımdır; %42 daha az teknik borç, %58 daha hızlı feature delivery ve %78 daha doğru mikroservis sınırı çizimi sağlar. Bounded context tanımı, context mapping, aggregate design ve ubiquitous language gibi pattern’ler iş paydaşlarıyla geliştiriciler arasındaki uçurumu kapatır. CQRS ve Event Sourcing entegrasyonu finansal ve regülatör yoğun domain’lerde audit ve scalability avantajları sunar. Doğru uygulama için domain expert dahil olma, event storming workshop’ları, küçük aggregate disiplini ve Conway uyumlu ekip yapısı kritiktir. Yanlış uygulanan DDD ise anemic domain model ve distributed monolith ile yıllık 800.000-2,5 milyon USD’lik kayba yol açabilir.
Ömer ÖNAL
Mayıs 17, 2026DDD’de bounded context çizmek teknik değil organizasyonel bir karar — Conway’s Law işliyor. Pratikte event storming workshop’ları olmadan bounded context’ler 6-12 ay sonra “distributed monolith”e dönüşüyor. Önce takım yapısını, sonra context map’i çizmek daha sağlıklı.