DDD paterninin bir çöküşü mü?
İlk önce birkaç yanılgıyı çözeyim.
DDD bir kalıp değildir. Ve gerçekten kalıpları reçete etmez.
Eric Evan'ın DDD kitabının önsözü şöyle:
Önde gelen yazılım tasarımcıları, etki alanı modellemesini ve tasarımını en az 20 yıl boyunca kritik konular olarak kabul ettiler; Hiçbir zaman net bir şekilde formüle edilmemiş olmasına rağmen, nesne topluluğunda düşük akım olarak ortaya çıkan bir felsefe, alan odaklı tasarım dediğim bir felsefe ortaya çıkmıştır.
[...]
Başarılar için ortak olan bir özellik, tasarım yinelemeleriyle gelişen ve projenin dokusunun bir parçası olan zengin bir alan modelidir.
Bu kitap, tasarım kararları almak için bir çerçeve ve alan tasarımını tartışmak için teknik bir kelime sağlar. Kendi içgörü ve deneyimlerimle birlikte geniş çapta kabul gören en iyi uygulamaların bir sentezidir.
Bu nedenle, yazılım geliştirme ve etki alanı modellemeye, ayrıca bu etkinlikleri destekleyen bazı teknik kelimelere (çeşitli kavram ve kalıpları içeren bir kelime bilgisi) yaklaşmanın bir yolu. Aynı zamanda tamamen yeni bir şey değil.
Akılda tutulması gereken bir başka şey de, bir etki alanı modelinin, sisteminizde bulunabilecek OO uygulaması olmadığıdır - onu ifade etmenin ya da bir kısmını ifade etmenin sadece bir yolu. Etki alanı modeli, yazılımla çözmeye çalıştığınız sorun hakkında düşünme şeklinizdir. Bir şeyi nasıl anladığın ve algıladığın, onlar hakkında nasıl konuştuğun. Bu kavramsal . Ama belli belirsiz bir anlamda değil. Derin ve rafine, sıkı çalışma ve bilgi toplamanın bir sonucudur. Daha da rafine ve zaman içinde büyük olasılıkla gelişti ve uygulama ile ilgili düşünceleri içeriyor (bazıları modeli kısıtlayabilir). Bu edilmelidir tüm ekip üyeleri tarafından paylaşılan (ve ilgili alan uzmanları dahil) ve sistemi nasıl uyguladığınızı yönlendirmeli, böylece sistem onu yakından yansıtmalıdır.
Bununla ilgili hiçbir şey, OO geliştiricileri genellikle modeli OO dillerinde ifade etmede daha iyi olsalar da ve birçok etki alanı kavramının ifadesi OOP tarafından daha iyi desteklense de, doğal olarak SQL karşıtı ya da karşıtı değildir. Ancak bazen modelin bölümleri farklı bir paradigmada ifade edilmelidir.
Merak ettiğim şey, çok karmaşık sorularım olduğunda ne olur [...]?
Genel olarak konuşursak, burada iki senaryo var.
İlk durumda, bir alanın bazı yönleri gerçekten karmaşık bir sorgu gerektirir ve belki de bu yön en iyi şekilde SQL / ilişkisel paradigmada ifade edilir - bu nedenle iş için uygun aracı kullanın. Etki alanınızdaki düşünceleri ve iletişim kurmada kullanılan dili düşünün. Etki alanı karmaşıksa, belki de bu, kendi sınırlanmış bağlamına sahip bir alt etki alanının bir parçasıdır.
Diğer senaryo, algılanan SQL'de bir şeyi ifade etme ihtiyacının kısıtlı düşüncenin bir sonucudur. Bir kişi veya ekip her zaman düşüncesine göre veritabanı yönelimli olmuşsa, eylemsizlik nedeniyle farklı şeylere yaklaşmanın farklı bir yolunu görmeleri onlar için zor olabilir. Bu, eski yöntem yeni ihtiyaçları karşılamadığında ve kutunun dışında düşünmeyi gerektiren bir problemdir. DDD, tasarıma bir yaklaşım olarak, kısmen etki alanı hakkındaki bilgileri toplayarak ve damıtıp bu kutudan çıkış yolunu bulma yollarıyla ilgilidir. Ancak herkes kitabın bu bölümünü görmezden geliyor gibi görünüyor ve listelenen bazı teknik kelime ve kalıplara odaklanıyor.