Anemiczne modele domen i zastrzyk usług domenowych

19

Anemiczne modelu domeny jest opisany jako anty-wzorzec w domenie napędzane projektu Martin Fowler. Aby mieć logikę biznesową w modelach domen, często używa się usług domenowych. Ale wprowadzanie usług domenowych do modeli domen jest uważane za szkodliwe przez Vaughna Vernona (patrz „Wdrażanie projektowania opartego na domenie, Strona 387).

Moim zdaniem opinie te są sprzeczne, czy to prawda? Jak można rozważyć oba punkty?

Czy to naprawdę bogaty model domeny z wprowadzonymi usługami domenowymi w porównaniu z anemicznym modelem domeny i zwykłymi usługami domenowymi ?

domain-driven-design dependency-injection services

— Sjoerd222888
źródło

4

Ja bynajmniej ekspertem w tej sprawie, ale myślałem, że ten rodzaj logiki, który udał się do domeny i usług podmiotów domena została zasadniczo różne. Logika wchodząca w byty jest logiką potrzebną do utrzymania obiektu w poprawnym stanie. Obejmuje to logikę walidacji i transformacji. Z drugiej strony usługi domenowe służą do logiki wyższego poziomu. Na przykład usługa domenowa modelowałaby proces biznesowy obejmujący wiele różnych rodzajów podmiotów, co jest złożonym sposobem.

— MetaFight,

2

@MetaFight: Nawet jeśli proces biznesowy wpływa na wiele podmiotów w skomplikowany sposób, możesz to osiągnąć bez usług, biorąc pod uwagę dobry model domeny Aggregate Root, czyli model domeny, który ma dostęp do wszystkich dotkniętych podmiotów jako właściwości lub pól na sobie.

— Greg Burghardt,

To ma sens :)

— MetaFight,

16

Anemiczny model to po prostu kontener danych. Nie zawiera zachowania. (Można to właściwie uznać za dobrą rzecz w paradygmacie funkcjonalnym.) Przeciwieństwem modelu anemicznego nie jest model pełen usług domenowych. Opisujesz dwie skrajności - obie są złe.

Jeśli masz model anemiczny, nie w pełni akceptujesz to, co oferuje OOP. Jeśli zaczniesz wprowadzać usługi do tych modeli, prawdopodobnie wprowadzasz obawy, które tam nie należą. Albo to, albo twój model jest bardziej anemiczny niż myślisz. Dlaczego miałbyś potrzebować usługi innej niż ta, która zapewnia coś, co jest wymagane, ale brakuje? (Brak może oznaczać anemię).

Unikanie obu „mówi” prowadzi do mocniejszego projektu. Czy masz w usłudze coś, czego potrzebuje model? Może powinien zostać przeniesiony do modelu. Jeśli nie, być może powinieneś ponownie rozważyć swoje obawy. Zachowanie modelu powinno działać wewnątrz modelu. Powinien głównie (jeśli nie tylko) dotyczyć członków. Pamiętaj jednak, że nadal będą rzeczy, które będą działać na lub z modelem. Na przykład modele nie powinny otwierać połączeń TCP ani nasłuchiwać zdarzeń interfejsu użytkownika, nawet jeśli są w jakiś sposób zaangażowane. To czyjeś odpowiedzialność i że ktoś nigdy nie należy wewnątrz modelu.

— Scant Roger
źródło

7

Dobrym rozróżnieniem, które lubię pamiętać, jest to, że model domeny implementuje logikę biznesową, a usługi domenowe wykonują logikę biznesową na modelach domen. Różnica polega na tym, kto do kogo dzwoni. Usługi mogą wywoływać metody modelu domeny. Jeśli Modele Domeny wywołują metody Usługi, odwróciłeś wzór na czubku głowy.

— Greg Burghardt,

7

To nie jest sprzeczne. Obaj zwolennicy chcieliby, abyś umieścił swój rzeczywisty kod w samym obiekcie domeny.

to znaczy.

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 usługi wstrzyknięte

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";
    }
}

Szczerze mówiąc, każde podejście ma plusy i minusy. Ten, który wybierzesz, jest w dużej mierze kwestią osobistych preferencji

— Ewan
źródło