Etki Alanına Dayalı Tasarım, bu kadar karmaşık olmayan alanlar için yararlı / üretken mi?

İşyerindeki potansiyel bir projeyi değerlendirirken, nesne modeline etki alanı odaklı bir tasarım yaklaşımı kullanmanın avantajlı olabileceğini önerdim. Projenin aşırı karmaşık bir alanı yok, bu yüzden iş arkadaşım bunu bana attı:

DDD'nin karmaşık bir alan modeli olduğu durumlarda olumlu olduğu söylenmiştir (“... Karmaşık, karmaşık bir alanda faaliyet gösterdiğimizde geçerlidir” Eric Evans).

Kaybettiğim şey - bir alanın karmaşıklığını nasıl tanımlarsınız? Etki alanı modelindeki toplam köklerin sayısı ile tanımlanabilir mi? Bir alanın nesnelerin etkileşimindeki karmaşıklığı mı?

Değerlendirmekte olduğumuz alan çevrimiçi yayıncılık ve içerik yönetimi ile ilgilidir.

Alternatif olarak uygulama davranışı olarak adlandırılan iş mantığının karmaşıklığı en önemli faktördür. İkinci en önemli faktör, teknik problem ile bu problemi tanımlamak için kullanılan ticari kelime dağarcığı arasında ne kadar boşluk olduğudur, çünkü DDD iş ve mühendislik ekibi arasında paylaşılan bir kelime dağarcığı oluşturmakla ilgilidir.

DDD'de kullanılan desenlerden bazıları, Depo deseni, Sınırlı Bağlam ve Katmanlı Mimari gibi kurumsal uygulama mimarisinde genellikle yararlıdır. Bu modelleri kullandığınız için, alan adı odaklı tasarım yaptığınız anlamına gelmez.

Çok fazla davranış yoksa, yani çoğunlukla veri depolıyorsunuz ve bu veriler üzerinde işlem yapmıyorsanız, o etki alanı katmanını oluştururken çok daha az değer olabilir. İçerik yönetiminde, yaptığınız tek şey onaylamak ve yayınlamaksa, belki de etki alanı yöntemleri yerine sistemdeki bayraklarla temsil edilebilir. Ancak ek davranış eklemeye başladığınızda, tam etki alanı katmanının uygunluğu daha belirgin hale gelir.

İçerik yönetiminden bahsediyorsak, DDD ihtiyacını ima etmeye başlayabilecek bazı (hayali) kurallar şunlardır:

• Hikaye xx / yy / zz tarihine kadar ambargo edilirse, önce yazdırmak için, ardından web'de yayınlayın; ambargo yoksa, web'de yayınlayın ve baskıya hazır hale getirin
• Bu hikayeyi, ücretli abonelere anında ödeme duvarının arkasında sunun; 2 hafta sonra kamuoyuna açıklandı.
• Bir hikaye yazıldıktan sonra, düzeltme, düzeltme okuma ve onay için bir editöre gönderin. Onaylandığında üretime gönderin. Üretim hikayeyi alan nedenleriyle keserse, genişletilmiş bir sürümü çevrimiçi kullanılabilir yapın.