Domain-driven design konusu her senior developer toplantısında bir şekilde karşıma çıkıyor. Birisi aggregate root’tan bahsediyor, biri bounded context’ten, biri ubiquitous language’dan. Çoğu zaman hiçbirinin gerçek DDD projesinde çalışmadığını 5 dakika sonra anlayabiliyorsun.
Gerçek şu: DDD güçlü bir araç, ama her projede değer katmıyor. Son 4 yılda en az 6 projede DDD prensiplerini kısmi olarak uyguladım. Bu yazıda hangi durumda değer, hangi durumda overkill olduğunu anlatacağım.
DDD ne zaman gerçekten kazanıyor?
Eric Evans’ın kitabı 2003’ten beri ortada. DDD özellikle şu senaryolarda ciddi bir fark yaratıyor:
1. Domain karmaşıklığı teknik karmaşıklıktan fazla olduğunda. Sigortacılık, finans, sağlık gibi alanlarda iş kuralları kod’dan önce geliyor. 50 sayfalık bir regülasyon dokümanı var, kod onu yansıtmak zorunda. DDD’nin ubiquitous language konsepti burada altın değerinde: iş uzmanıyla geliştirici aynı terminolojiyi kullanıyor, yarı yolda kaybolmuyor.
2. Uzun ömürlü, kritik business logic’li sistemlerde. 5 yıl sonra da yaşayacak, belki daha fazla ekip tarafından geliştirilecek sistemler. Bounded context sınırları ekip organizasyonuna da yol gösteriyor: Conway yasasıyla aynı yönde çalışıyorsunuz.
3. İş uzmanının geliştirici ekibinden kopuk olduğu yapılarda. Müşteri iş uzmanı Ankara’da, ekip İstanbul’da. DDD’nin event storming ve domain modeling workshop’ları bu iletişim boşluğunu kapatıyor.
DDD ne zaman overkill?
1. Basit CRUD projelerde. Bir landing page admin paneli, bir içerik yönetim sistemi, bir katalog uygulaması. Domain karmaşık değil. Aggregate root’ları, value object’leri, domain event’leri ortaya atmak 3 günlük bir işi 3 haftaya uzatıyor.
2. Tek geliştiricili ürünlerde. DDD’nin organizasyonel avantajları 2-3 ekip arası sınırlar koyduğunda değer kazanıyor. Tek başına çalışıyorsan repository, entity, service katmanlarına ayırmak sadece boilerplate ekliyor.
3. Prototype veya MVP aşamasında. Ürünün hayatta kalıp kalmayacağı belli değilken DDD yatırımı yapmak para kaybı. Önce ürün-pazar uyumu, sonra mimari.
Başlamak için minimum set
DDD’yi tamamen uygulamak pahalı ama belirli prensipler her projeye değer katıyor:
Ubiquitous language. İş uzmanının kullandığı terimleri kodunuzda da kullanın. orderFulfillment yerine siparişHazırlama, paymentCapture yerine ödemeOnaylama gibi. İş konuşmasıyla teknik konuşmanın arasında tercüme yapmak zorunda kalmıyorsunuz.
Bounded contexts. En azından modüllerinizin sınırlarını belirleyin. Kullanıcı yönetimi, ödeme, envanter, sipariş, raporlama bunlar farklı context’ler. Aynı User modeli hepsinde kullanılamaz, her context’in kendi User görünümü olmalı.
Aggregate boundaries. Bir transaction’da hangi veriler atomik olarak değişmeli? Bu sorunun cevabı aggregate sınırını veriyor. Aggregate dışı bir şeyi güncelliyorsanız eventually consistent yaklaşım gerekiyor.
Bu üç kavram DDD kitabının %70’ini anlamadan da pratik değer sağlıyor.
Pratik uygulama ipuçları
Danışmanlıkta ekiplerle DDD başlatırken genelde şu sırayı öneriyorum:
- Event storming workshop’u ile business event’leri listele. Her event bir iş olayını temsil ediyor.
- Event’leri gruplara ayır, her grup muhtemel bir bounded context.
- Her context’in sorumluluklarını yaz. Context’ler arası iletişim (event, API, veri kopyası) tanımla.
- İlk aggregate’i seç, kodla. Test et, iterate et.
Bu 4 adım genelde 2-3 haftalık bir discovery fazı. Ondan sonra implementation’a geçiliyor.
Çoğu ekibin yaptığı hata
DDD’ye başlayan çoğu ekibin en yaygın hatası, teknik patern’leri domain’den önce öne çıkarması. “Repository, Factory, Specification pattern kullanalım” diyorlar, ama hangi domain’i modellediklerinden haberdar değiller. Sonuç: boilerplate’le dolu, business logic eksik bir kod tabanı.
Tersi işe yarıyor. Önce domain model çıkarıyorsun, sonra teknik patern sadece mekanik destek olarak ekleniyor.
Sonuç
DDD’yi “tamamen uygula veya hiç uygulama” şeklinde düşünme. Ubiquitous language ve bounded context prensiplerini çoğu ürüne uyarlayabilirsin, bu tek başına değer katıyor. Aggregate root, event sourcing, CQRS gibi daha ağır kavramları ancak domain karmaşıklığı onu gerektirdiğinde ekle.
Kararı verirken kendine sor: domain karmaşıklığımı modelsiz yönetebiliyor muyum? Ekibin bir parçası iş uzmanıyla konuşup gerçek ihtiyaçları kodla buluşturuyor mu? Cevaplardan biri hayır ise DDD’nin ilk prensipleri yardımcı olur. İkisi de evet ise fancy pattern’lere ihtiyacın yok.