Anemik alan modelleri ve alan hizmetleri enjeksiyonu

19

Anemik alan modeli Martin Fowler alan odaklı tasarım bir anti-desen olarak tarif edilmektedir. Etki alanı modellerinde iş mantığına sahip olmak için genellikle etki alanı hizmetleri kullanılır. Ancak, etki alanı hizmetlerinin etki alanı modellerine enjekte edilmesi Vaughn Vernon tarafından zararlı olarak kabul edilir (bkz. "Etki Alanına Dayalı Tasarımın Uygulanması, Sayfa 387).

Bence bu görüşler çelişkilidir, bu doğru mu? Her iki nokta nasıl değerlendirilebilir?

Anemik etki alanı modeli ve normal etki alanı hizmetlerine karşı etki alanı hizmetleri enjekte edilen gerçekten zengin etki alanı modeli mi?

domain-driven-design dependency-injection services

— Sjoerd222888
kaynak

4

Bu konuda hiç uzman değilim, ancak alan adı hizmetlerine ve alan varlıklarına giren mantığın türünün temelde farklı olduğunu düşündüm . Varlıklara giren mantık, nesneyi doğru durumda tutmak için gereken mantıktır. Bu, doğrulama ve dönüşüm mantığını içerir. Etki alanı hizmetleri ise daha üst düzey mantık içindir. Bu nedenle, örneğin, bir etki alanı hizmeti, birden çok farklı varlık türünü içeren bir iş sürecini karmaşık yollarla modelleyecektir.

— MetaFight

2

@MetaFight: Bir iş süreci birden çok varlığı karmaşık yollarla etkilese bile, bunu iyi bir Toplam Kök etki alanı modeli, yani etkilenen tüm varlıklara kendi özellikleri veya alanları olarak erişimi olan bir etki alanı modeli verilen hizmetler olmadan gerçekleştirebilirsiniz.

— Greg Burghardt

Bu mantıklı :)

— MetaFight

16

Anemik model basitçe bir veri kabıdır. Davranış içermiyor. (Bu aslında işlevsel paradigmada iyi bir şey olarak düşünülebilir.) Anemik bir modelin tersi , alan hizmetleriyle dolu bir model değildir . İki uç tanımladınız - ikisi de kötü.

Anemik bir modeliniz varsa, OOP'un sunduklarını tam olarak kucaklamıyorsunuz. Bu modellere servis enjekte etmeye başlarsanız, muhtemelen oraya ait olmayan endişeleri enjekte edersiniz. Ya o ya da modeliniz düşündüğünüzden daha anemiktir. Neden gerekli olan ancak eksik bir şey sunma dışında başka bir hizmete ihtiyacınız var? (Eksik anemik anlamına gelebilir.)

Her iki "anlatımdan" kaçınmak daha güçlü tasarıma yol açar. Bir hizmette modelin ihtiyaç duyduğu bir şey var mı? Belki de modele taşınmalıdır. Değilse, belki endişelerinizi yeniden düşünmelisiniz. Bir modelin davranışı model içinde çalışmalıdır . Çoğunlukla (sadece değil) üyelerle de ilgilenmelidir. Ama unutmayın, hala bu işe şeyler olacak üzerinde veya birlikte modelin. Örneğin, modeller bir şekilde dahil olsalar bile TCP bağlantılarını açmamalı veya UI olaylarını dinlememelidir. Bu başkasının sorumluluğundadır ve asla modelin içinde yer almaz.

— Scant Roger
kaynak

7

Hatırlamak istediğim iyi bir ayrım, Etki Alanı Modelinizin iş mantığını uygulaması ve Etki Alanı Hizmetlerinizin Etki Modeli'nde iş mantığını yürütmesidir . Aradaki fark kimin kimi çağırdığı. Hizmetler Etki Alanı Modeli yöntemlerini çağırabilir. Etki Alanı Modelleri Hizmet yöntemlerini çağırıyorsa, deseni başının üstüne çevirdiniz.

— Greg Burghardt

7

Bu çelişkili değil. Her iki taraftar da gerçek kodunuzu alan adı nesnesinin içine koymanızı ister.

yani.

public class Order
{
    private string status = "not bought";
    public void Buy()
    {
        this.status = "bought";
    }
}

vs ADM

public class Order
{
    public string Status = "not bought";
}

public class BuyingService
{
    public Order Buy(Order order)
    {
         Order o = new Order();
         o.status = "bought";
         return o;
    }
}

vs enjekte edilen hizmetler

public class Order
{
    public Order(IBuyingService bs)
    {
        _bs = bs;
    }
    private IbuyingService _bs;
    private string status = "not bought";
    public void Buy()
    {
        this.status = _bs.Buy();
    }
}

public class BuyingService : IBuyingService
{
    public string Buy()
    {
         return = "bought";
    }
}

Açıkçası her yaklaşımın artıları ve eksileri var. Seçtiğiniz, büyük ölçüde kişisel tercih meselesidir

— Ewan
kaynak