Domain Driven Design

Domain-Driven Design, karmaşık yazılım sistemleri geliştirirken karşılaşılan temel problemlere çözümler öneren bir yaklaşım. DDD, yazılım tasarlanırken tüm süreçlerin domain’i esas alarak kurgulanmasını tavsiye ediyor. Konunun ehli Eric Evans “Domain-Driven Design – Tackling Complexity in the Heart of Software” isimli kitabında, kompleks sistemlerde oluşan problemlerin kaynağının çoğunlukla domain’in içinde gizli olduğunu söylüyor. Peki nasıl uygulanıyor bu DDD?

Diyelim ki bir havayolları yazılım sistemi geliştiriyoruz. Biz yazılımcı olarak, ne uçakların hangi koşullarda iniş yaptığını, ne kargoların hangi formüllerle hesaplandığını, ne de havayolu trafiğinin nasıl yönetildiğini biliriz. Bunları bilen kişiye “domain expert”, yani işin ehli diyoruz. Bu kişiler yazılım geliştirmeyi bilseler herşey çok güzel olabilirdi ama, o konuda bize ihtiyaç duyuyorlar. Dolayısıyla bize havayollarını anlatmaları gerekiyor.

Bize tüm işi güzel güzel doğal dille anlatıyorlar, dinliyoruz, not alıyoruz. İhtiyaçlarını belirliyoruz, sistemi modellemeye başlıyoruz. Bir seferde olmuyor ama tabi, tekrar tekrar sorular soruyoruz çünkü bizim işimiz domain’in problemini yazılım dünyasında ifade etmek ve yazılım dünyasında ona çözüm üretmek. Yalnız yazılım dünyasıyla gerçek dünya arasında çok fark var. Biz dünyayı sınıflar, metodlar, algoritmalar olarak görüyoruz, aklımıza polymorphism, inheritence geliyor, pattern’ler geliyor, ama aslında bu gerçek dünya için hiçbir şey ifade etmiyor. Yani ayrı dillerden konuşuyoruz. Bu noktada DDD diyor ki, ilk önce bir ortak dil geliştirmek lazım, bu dile de “Ubiquitous Language” diye komik bir isim verelim. Domain ile ilgili bilgiyi veren kişiler ile ortak bir dil geliştirelim, onlar bize anlatacaklarını hep o dilin kelimeleriyle anlatsınlar, biz de sınıflarımıza, metodlarımıza o dilin kavramlarını kullanarak isim verelim. En azından aşağı yukarı aynı şeylerden bahsediyor hale gelelim.

Dil konusundan sonra, biraz da yazılımı modelleme esnasında katmanlı bir yapı oluşturmaktan bahsediyoruz. Domain Driven Design, “Presentation Layer”, “Application Layer”, “Domain Layer” ve “Infrastructure Layer” olarak dört katman üzerinde sistemi kurgulamayı öneriyor. Burada Domain katmanı sistemin temelini oluşturuyor ve tüm domain nesneleri, iş kuralları (business rules) gibi domain’le alakalı kavramları burada tanımlıyoruz. Son olarak domain katmanını mümkün olduğunca diğer katmanlardan izole etmeye, yani bağlılığını azaltmaya çalışıyoruz. Basitçe ifade etmek gerekirse, domain katmanında işi tanımlıyor ve diğer katmanlları domain katmanına servis edecek şekilde tasarlıyoruz. DDD, katmanlı yapıyı bu şekilde tasarlayabilmemiz için bazı tasarım blokları öneriyor. Eric Evans yukarıda bahsedilen kitabında bu blokları detaylı olarak anlatıyor.

Biliyoruz ki “Refactoring” karmaşık sistemler için çok baş ağrıtan bir konu. Kompleks bir sistemi tam olarak modellemek oldukça zordur, mutlaka açıkta kalan, net olmayan konseptler olacaktır. Domain Driven Design bu konuda bazı öneriler sunuyor. DDD’ye göre, refactoring sürekli devam etmeli ve domain’in soyut olarak kalmış tüm kavramları aranarak bunlar somut olarak sistemde ifade edilmeli. Yani anlaşılmamış veya belirsizlik içeren herşey açıklığa kavuşmalı. Bunu sağlamada yardımcı olması amacıyla üç yöntem öneriliyor (Constraint, Process, Specification). Aşağıda bağlantısını verdiğim araştırma makalemden bu yöntemler hakkında detaylı bilgi edinebilirsiniz.

DDD’nin son olarak dikkat çektiği konu, model bütünlüğünü sağlamak. Büyük sistemlerin modelleri de büyük olur ve bir noktadan sonra modelin bütününe yukarıdan bakmak pek mümkün olmayabilir. Modelin alt modelleri, servisleri, modülleri gibi tüm alt elemanları tek başlarına bile oldukça kapsamlıyken, modelin bütünlüğünü sağlamak ve sürdürmek başlı başına bir mesele olacaktır. DDD, bir modelin alt elemanlarını gruplayıp, her alt modelin fonksiyonalitesine ve karakteristiğine göre onları verimli şekilde organize etmek konusunda yardımcı olacak bazı yöntemler ve pattern’ler tanımlıyor. Bu pattern’ler de detaylı olarak makaledeki kaynaklardan incelenebilir.

Eric Evans bir röportajında diyor ki Domain-Driven Design yazılım dünyasının popüler konularından birisi oldu ve kapsamlı yazılım projelerinde kullanılıp faydası görüldükçe yaygınlaşacak, ilgili konseptleri daha da geliştirilecek. Buna ek olarak, “Görmemişin DDD’si olmuş, tutup projesine takmış” durumuna da düşmeyin diyor. DDD’yi heryerde kullanmıyoruz, yalnızca gerektiği yerde gerektiği oranda uygulayıp, gerekmediği yerde unutuyoruz. Çünkü Domain-Driven Design,  olduğu gibi alıp projenizi üstüne oturttuğunuz bir kalıp değil, bazı yöntemler öneren teorik bir yaklaşım.

DDD ile ilgili yazdığım araştırma makalesi : https://alifindik.wordpress.com/wp-content/uploads/2011/06/domain-driven-design-findik_ali.pdf