Domain Driven Design 101
Yazılımın kalbi, kullanıcısı için domain ile ilgili problemlemleri çözebilme yeteneğidir.
Eric Evans
Domain-Driven Design (DDD) kompleks domain problemlerine sahip yazılımları geliştirmek için bir dil ve domain merkezli bir yaklaşımdır. DDD terimi Eric Evans tarafından “Domain-Driven Design: Tackling Complexity in the Heart of Software” kitabında ortaya konmuştur.
DDD hem teknik hem de iş alanlarında karmaşıklığı sahip yazılımları üreten ekiplerin başarıya odaklanması için bazı pattern ve prensiplerden oluşur.
Yazılımın sahip olduğu kompleksite, domain’den katılsal olarak gelen kompleksite ile teknik kompleksitenin birleşmesi sonucu ortaya çıkar.
Kompleks Problemleri Domain Modelleri Kullanarak Çözün
Bir domain modeli gerçekliği değil, bir perspektifi ifade eder. Bu perspektif ise çözülmek istenen problemdir. Bu modelin çeşitli ifadeleri olan kod, diyagram, döküman ise aynı dil ile bağlıdır.
Model, yalnızca yaratılan uygulama bağlamındaki sorunları çözmek için ilgili olan detayları içerir. Yeni use case’ler domain’e dahil oldukça, model’in geçerli kalabilmesi için sürekli olarak gelişmeye ihtiyacı vardır.
- İlk iyi fikrinizde durmayın.
- Her yeni problem ile birlikte modelinizi sorgulayın.
- Gerçek hayatı modellemeye çalışmayın.
Yazılım projelerinin en karmaşık kısmı domain’in kendisini anlamaktır.
Eric Evans
Ubiquitous Language Kullanarak Model Dizayn Etmek
Yazılım çözümleri genellikle kötü iletişim ve domain ile teknik dil arasındaki terminoloji farklılıklarından dolayı başarısız sonuçlanır.
Ubiquitous Language, teknik ve domain çeviri maliyetini en aza indirir ve tüm ifadeleri “true model” olarak da bilinen kod modeline bağlar. Paylaşılan bir dil, modelleme sırasında keşiflere de yardımcı olur ve domain’e derinlemesine bir hakimiyet oluşturabilir.
Ubiquitous Language modelin kod implementasyonu yapılırken class isimlerinde, property’lerde ve metod isimlendirmelerinde aynı şekilde kullanılmalıdır. DDD’nin sürekli gelişmesi modeli bu ortak dili kullanmaktan geçmektedir.
Ubiquitous Language Kullanarak Model Dizayn Etmek
Yazılım çözümleri genellikle kötü iletişim ve domain ile teknik dil arasındaki terminoloji farklılıklarından dolayı başarısız sonuçlanır.
Herhangi bir programcı, bilgisayarın anlayabileceği şekilde kod yazabilir. İyi programcılar ise insanların anlayabileceği kodlar yazar.
Martin Flower
İşbirlikçi ve Sürekli Gelişen Modelleme
İşbirlikçi modellemenin en büyük yararlarından biri iş birimi tarafından sürekli olarak geri bildirim alıyor olmaktır. Sürekli geri bildirim alıyor olmak, development takımının modelde neyin önemli olup olmadığını fark etmesi için oldukça önemlidir.
Karışık ve Büyük Modelleri Bounded Context’lere Ayırın
Zamanla modeliniz bütünlüğünü ve kendini açıkça ifade edebilme özelliğini kaybedebilir, kompleksitesi artar ve üzerinde çalışan takımların kullandığı dil ifadesizleşebilir. Bu durumda, büyük ve kompleks modeller, bir modelin belli bir bağlamda anlaşılabileceği sınırlarda bounded context’lere ayrılmalıdır.
Bunu yapamadığınız takdirde ise, yazılımınızın “big ball of mud” modeline dönmemesi ihtimali çok düşüktür.
Context’lerde Önemli Noktalara Dikkat Edin
DDD’nin Göze Çarpan Noktaları
Kompleks domain’lere sahip yazılımları efektif ve bakım yapılabilir şekilde ortaya koyabilmek için iteratif döngülerle çalışan kendini adamış takımlara ihtiyaç vardır. Eric Evans’ın gözlemlemiş olduğu üzere teknik yetkinlikler size sadece bir yere kadar götürebilir. Problem domain’ine odaklanılmayan, domain expert’leri ile çalışmayan yada ubiquitous language kullanımına dikkat edilmeyen bir ortam sizi “big ball of mud” modeline sürükleyebilir.
Önemli Noktalara Efor Harcayın
Her tasarladığınız sistem iyi tasarlanmak zorunda değildir ki sürekli bunu istemek bütçeniz için iyi olmaz. Bunun yerine core domain’inizi tanımlayıp eforunuzu buraya harcamak daha mantıklı olacaktır. Zaten ortaya çıkaracağınız yazılıma yol açan şey core domain’dir.
DDD uygulaması zor ve zaman alıcı bir yöntemdir bu yüzden bazen sadece kodlamaya başlamak, problem olmayan bir yerde problem aramaya çalışmaktan iyidir.
Bounded Context İçinde Modelleme
Büyük bir domain için modelleri oluştururken, eğer birden fazla ekip varsa, kullanılan dil açıklığını kaybedebilir. Bu yüzden domain ilk olarak context’lere ayrılıp, modelleri bunun üstünden geliştirmelisiniz. Bu noktada context herşeydir; context ve izolasyon kodunuzun bütünlüğünü sağlar ve birden fazla ekibin aynı anda çalışabilmesini sağlar.
Modelin Kendisini Ubiquitous Language ile İfade Etmesi
Yazılım projeleri kötü iletişim ile birlikte, domain ile teknik terminoloji arasındaki dönüşüm maliyeti yüzünden başarısız sonuçlanabilir.
Ubiquitous Language, development ekibinin kod modelini, domain expert’leri ile yapılan konuşmalar ve diyagramlar gibi ifade şekillerine bağlamasını sağlayarak daha etkili bir iletişim sağlar. Bu nedenle, kod modelinin Ubiquitous Language kullanılarak açıkça ifade edilmesi hayati önem taşımaktadır ve Ubiquitous Language’e takıntılı olmak oldukça önemlidir.
Modelleme ve Gelişimde İşbirliği
Yazılımcılar ile domain expert’lerinin sürekli olarak iş birliği içinde olması ile ortaya çıkan öğrenmenin göz ardı edilmemelidir. Bilginin yoğun şekilde paylaşılması sürekli olarak devam edecek bir süreçtir, bir projenin başlaması gibi olaylar ile sınırlı kalmamalıdır. Derin bilgi hakimiyeti, problemli domain üstünde ancak sürekli olarak geliştirme döngüsü sonucunda elde dilebilir. “Çalışan yazılım genellikle öğrenmenin çıktısıdır” şeklinde de söylenebilir.
Yazının sunum haline https://metinirden.github.io/ddd-101/ adresinden ulaşabilirsiniz :)
