Bir muhasebecinin "cari", bir depocunun "sevk", bir satışçının "teklif" dediği kavramlar, yazılımda çoğu zaman Table1, Status = 3 veya ProcessData() gibi anlamsız ifadelere dönüşür. Domain-Driven Design (DDD), bu kopukluğu gidermeyi hedefler: yazılım, işin diliyle konuşmalıdır.
Ortak dil (Ubiquitous Language)
DDD'nin ilk ve belki en değerli fikri, iş uzmanları ile geliştiricilerin aynı kelimeleri aynı anlamda kullanmasıdır. Toplantıda "irsaliye kesildi" deniyorsa kodda da Irsaliye.Kes() olmalıdır. Bu dil sözlük gibi yazılı tutulur ve kod, dokümanlar ve konuşmalar arasında tutarlı kalır. Bkz. isimlendirme kuralları.
Bounded Context (Sınırlı Bağlam)
Aynı kelime farklı departmanlarda farklı anlama gelebilir. "Ürün" satış için fiyat ve görsel demektir; depo için raf yeri, ağırlık ve barkod. Tek bir dev Urun sınıfı yerine, her bağlamda o bağlamın ihtiyacına uygun modeller kurulur. Bağlam sınırları, ileride uygulamayı modüllere veya servislere bölmek için de en doğal çizgilerdir.
Yapı taşları
Entity
Kimliğiyle ayırt edilen nesnelerdir. İki müşterinin adı aynı olsa da farklı müşterilerdir.
Value Object
Değeriyle tanımlanan, değişmez nesnelerdir: Para, Adres, EpostaAdresi. 100 TL, başka bir 100 TL ile aynıdır.
public record Para(decimal Tutar, string ParaBirimi)
{
public Para Topla(Para diger) =>
diger.ParaBirimi == ParaBirimi
? this with { Tutar = Tutar + diger.Tutar }
: throw new InvalidOperationException("Para birimleri farklı.");
}C#'taki record tipleri value object yazmayı çok kolaylaştırır.
Aggregate
Birlikte tutarlı kalması gereken nesnelerin grubudur. Bir Siparis ve kalemleri bir aggregate'tir; kalemler yalnızca sipariş üzerinden değiştirilir, böylece "toplam tutar" kuralı hiçbir zaman bozulmaz.
Domain Event
İş açısından anlamlı bir olayın kaydıdır: SiparisOnaylandi, OdemeAlindi. Diğer parçalar bu olaylara tepki verir; sistem gevşek bağlı kalır.
Zengin model, anemik model
Anemik modelde sınıflar yalnızca veri taşır, kurallar başka yerlerdedir. Zengin modelde ise kurallar verinin yanında yaşar:
siparis.Onayla(); // durum kontrolü, tarih ataması ve olay üretimi içerideBu, kuralın unutulmasını ve farklı yerlerde farklı uygulanmasını önler.
DDD ne zaman değer katar?
- İş kuralları karmaşık ve sık değişiyorsa
- Birden çok departmanın farklı bakış açıları varsa
- Yazılım işletmenin rekabet avantajının parçasıysa
Basit veri girişi ve listeleme uygulamalarında DDD'nin tüm araçları gereksiz ağırlık yaratır; ancak ortak dil fikri her projede faydalıdır. Mimari yerleşim için bkz. Clean Architecture.
Sık sorulan sorular
DDD ile mikroservis aynı şey mi?
Hayır. DDD bir modelleme yaklaşımıdır; bounded context'ler mikroservis sınırları için iyi bir rehber olabilir ama monolit bir uygulamada da DDD uygulanabilir.
Küçük bir ekip DDD kullanabilir mi?
Evet; özellikle ortak dil, value object ve aggregate fikirleri küçük ekiplerde de kod kalitesini belirgin şekilde artırır.
Sonuç
DDD, yazılımı işin gerçek yapısına göre şekillendirmenin yoludur. İş dilini koda taşımak, hem geliştiriciler hem de işletme için yanlış anlaşılmaları azaltır ve yazılımın işle birlikte büyümesini sağlar.
