domain driven design

domain driven design, yazılım ekibinin “abi tabloyu oluşturalım, gerisi gelir” kafasından çıkıp, yaptığı işin ne bok olduğunu anlamaya başlamasıdır.

çünkü yazılımda en büyük yalan şudur:

önce kodu yazalım, iş kuralları sonra oturur.

oturmaz.

iş kuralları sonra oturmaz, kodun üstüne çöker. önce küçük bir if gelir. sonra bir flag. sonra “bu müşteri tipi farklı”. sonra “ama kurumsalda böyle değil”. sonra “şu kampanya sadece bayi kanalında geçerli”. sonra “ama iade edilmiş fatura kısmi kapatılmışsa stok hareketi farklı çalışacak”.

bir bakmışsın sistem değil, if-else mezarlığı yazmışsın.

domain driven design tam burada devreye girer.

der ki: kardeşim, sen yazılım yazmıyorsun. bir iş alanının dijital modelini kuruyorsun. önce o iş alanını anlayacaksın. adam otel yönetim sistemi yapıyor ama rezervasyon nedir bilmiyor. e-ticaret yazıyor ama sipariş, ödeme, fatura, iade, stok, kargo arasındaki ilişkiyi çorba yapıyor. muhasebe modülü yazıyor ama “cari” kelimesini sadece tablo adı sanıyor.

sonra production’da sistem patlayınca suç entity framework’e kalıyor.

hayır kardeşim.

sorun framework değil.

sen işi anlamadan kod yazmışsın.

ddd’nin özü şudur: yazılımın merkezi veritabanı değil, domain’dir. yani işin kendisi. müşterinin dünyasında hangi kavramlar var, hangi kurallar var, hangi sınırlar var, hangi kelime ne anlama geliyor, hangi işlem hangi sonucu doğuruyor; önce bunları anlarsın. sonra kodu bunların etrafına örersin.

yani tablo değil, anlam tasarlarsın.

bu cümleyi fazla şiirsel bulana da şunu diyelim:

anlamı tasarlamazsan, migration dosyalarıyla ağıt yakarsın.

domain driven design’ın en güzel tarafı, yazılımcıyı “ben kodumu yazarım, müşteri düşünsün” rahatlığından çıkarır. çünkü müşteri bazen düşünemez. domain expert dediğin adam işi bilir ama yazılıma dökemez. yazılımcı da kod bilir ama işi bilmez. iki taraf da kendi dilinde konuşursa ortaya sistem değil, çeviri kazası çıkar.

müşteri der ki:

“rezervasyon opsiyonlu olsun.”

yazılımcı der ki:

“boolean atalım mı?”

işte ddd burada gelir ve masaya tokadı vurur.

opsiyon nedir? ne zaman başlar? ne zaman düşer? ödeme alınırsa ne olur? oda bloke edilir mi? süresi dolarsa kim serbest bırakır? manuel uzatılabilir mi? aynı oda başka kanala açılır mı? iptal olursa geçmiş kayıt nasıl tutulur?

soru sormayan yazılımcı kod yazmaz.

saatli bomba kurar.

ddd, soru sorma disiplinidir.

ama öyle “temiz mimari yapalım, klasörleri ayıralım” seviyesinde değil. o işin makyaj kısmı. ddd’yi sadece entity, aggregate, value object, repository diye ezberleyen adam, kebapçıya gidip menüyü yemeye çalışan adam gibidir. kavramları biliyor ama ne işe yaradığını anlamıyor.

aggregate root yazmış.

ama root niye root, bilmiyor.

value object yazmış.

ama değerin kimliği olmadığını içselleştirmemiş.

bounded context demiş.

ama her modülü aynı dbcontext’e gömmüş.

ubiquitous language demiş.

ama müşteri “ön ödeme” diyor, kodda “advancepayment”, panelde “kapora”, raporda “depozito” yazıyor.

tebrikler.

çok dilli kaos kurdun.

ddd’nin en kritik olayı ubiquitous language denen şeydir. yani herkesin aynı dili konuşması. iş tarafı ne diyorsa kod da onu diyecek. panel de onu diyecek. rapor da onu diyecek. domain event de onu diyecek. bir yerde “sipariş”, başka yerde “order”, başka yerde “talep”, başka yerde “basket checkout record” yazıyorsa geçmiş olsun. sistem daha başlamadan kişilik bölünmesi yaşamış.

yazılımda isimlendirme estetik değildir.

isimlendirme hafızadır.

yanlış isim, yanlış model doğurur.

yanlış model, yanlış karar doğurur.

yanlış karar, gece 03:00’te “abi acil bakabilir misin” mesajı doğurur.

bounded context de ddd’nin en hayat kurtaran ama en çok yanlış anlaşılan tarafıdır. her kavram her yerde aynı anlama gelmez. “müşteri” satışta başka şeydir, muhasebede başka şeydir, destek tarafında başka şeydir. satış için müşteri aday olabilir. muhasebe için cari hesaptır. destek için ticket açan kişidir.

sen bunların hepsini tek customer tablosuna gömersen sistem büyümez.

şişer.

sonra da patlar.

bounded context der ki: kavramın sınırını bil. her şeyi tek modelde birleştirmeye çalışma. çünkü gerçek hayat da tek model değildir. bir otelde “oda” resepsiyon için satılabilir envanterdir, temizlik için iş kalemidir, teknik servis için arıza lokasyonudur, muhasebe için gelir kaynağıdır.

aynı kelime.

farklı bağlam.

bunu anlamayan yazılımcı “roomentity” diye bir canavar yaratır. içinde fiyat var, temizlik durumu var, bakım durumu var, rezervasyon durumu var, fotoğraf var, seo slug var, sensör verisi var, personel notu var.

o artık entity değil.

otel enkazı.

ddd’nin aggregate mantığı da burada önem kazanır. her şeyi her yerden değiştiremezsin. kuralların merkezi olur. mesela siparişin kalemleri vardır, toplamı vardır, ödeme durumu vardır. dışarıdan gidip sipariş kalemini kafana göre değiştiremezsin. siparişin kuralı neyse oradan geçersin.

çünkü domain model, veri torbası değildir.

kural taşıyan canlı dokudur.

anemic domain model denen şey de yazılım dünyasının protez karakteridir. entity var ama ruh yok. bütün kurallar service sınıflarında dağılmış. customer sadece property torbası. order sadece getter setter müzesi. ınvoice zaten veritabanı satırının cosplay hali.

sonra ekip der ki:

“ddd yaptık.”

hayır.

sen klasör açtın.

ddd yapmadın.

gerçek ddd’de entity davranış taşır. value object anlam taşır. domain service gerçekten domain’e ait olan ama entity’ye sığmayan kuralı taşır. application service orkestrasyon yapar, domain’in işine burnunu sokmaz. ınfrastructure kenarda durur, domain’in üstüne çamurlu botla basmaz.

iyi mimaride domain merkezdir.

kötü mimaride domain, orm’nin altında ezilmiş mağdur vatandaş gibidir.

repository meselesi de ayrı komedi. ddd öğrenen herkes ilk gün repository açıyor. sonra her tabloya repository. customerrepository, orderrepository, productrepository, ınvoicerepository, paymentrepository, allahrepository.

kardeşim dur.

repository pattern veritabanı fetişi değildir. aggregate erişimini kontrol etmek içindir. her tabloya repository açınca mimari yapmış olmuyorsun. sadece dao’ya takım elbise giydiriyorsun.

ddd’nin en sevdiğim tarafı şu: yazılımı işin gerçeğine yaklaştırır. kod, müşterinin dünyasını daha doğru temsil etmeye başlar. bir bug çıktığında sadece teknik hata değil, modelleme hatası diye bakarsın. “bu if niye burada?” diye sorarsın. “bu kural bu context’e mi ait?” diye sorarsın. “bu kavram gerçekten aynı kavram mı?” diye sorarsın.

ve bazen acı cevap gelir:

hayır, değilmiş.

üç aydır aynı isimle iki farklı şeyi modellemişiz.

işte o an ddd tokadı yenir.

tabii ddd’nin de hastalıklı kullanımı var. her projeye ddd basılmaz. basit crud paneline event storming, aggregate, domain event, cqrs, bounded context, hexagonal architecture, outbox pattern, saga falan gömersen proje değil, mimari düğün salonu kurarsın.

müşteri iki tablo istiyor.

sen tactical design konferansı açıyorsun.

bu da saçmalık.

ddd karmaşık domain içindir. iş kuralları derinse, kavramlar karışıyorsa, farklı departmanlar aynı kelimeyi farklı anlamda kullanıyorsa, sistem büyüyecekse, yanlış model pahalıya patlıyorsa; ddd altın değerindedir.

ama “ürün ekle, listele, sil” projesine ddd diye beş katman açmak, tost makinesine nükleer reaktör bağlamak gibidir.

çalışır mı?

belki.

mantıklı mı?

değil.

domain driven design’ın asıl gücü teknik şovda değil, zihniyet değişimindedir. yazılımcıya şunu öğretir:

kod yazmadan önce anlamı anla.

müşterinin kelimelerini hafife alma.

her kavramın sınırı vardır.

iş kuralı controller’da yaşamaz.

veritabanı tasarımı domain tasarımı değildir.

her şeyi tek modele gömmek birlik değil, felakettir.

ve en önemlisi:

işi anlamayan yazılımcı, sadece daha hızlı yanlış kod yazar.

özetle domain driven design; yazılımın “müşteri ne istiyorsa yaparız abi” seviyesinden çıkıp, “müşterinin dünyasını doğru modellemezsek hepimiz yanarız” seviyesine gelmesidir.

temiz mimari değildir sadece.

klasör düzeni değildir.

repository festivali değildir.

entity’ye zırh giydirip domain demek hiç değildir.

ddd, işin kalbine girip oradaki pisliği, kuralı, istisnayı, dili, sınırı ve gerçeği koda taşıma disiplinidir.

iyi yapılırsa sistem omurga kazanır.

kötü yapılırsa zaten kötü olan projeye bir de entelektüel sis bombası atarsın.

ve production patlayınca herkes aynı soruyu sorar:

“bu domain kimin domain’iydi?”

cevap genelde bellidir.

kimse sahiplenmez.