Martin Fowler uważa model domeny anemicznej za anty-wzór.

Przetaczanie modelu trwałości, gdy model domeny wydaje się być poważnie wyłączony z powoduObiektowa relacyjna impedancja Missmatch. W przypadku uporczywości i normalizacji mamy tendencję do rozbijania klas na bardzo małe drobne kawałki, a metody klasowania na tych klasach są głupie. Plus trwałość rzadko się zmienia, ale logika biznesowa trochę się zmienia.

Potrzebujemy więc modelu DomainModel, który opiera się na modelu trwałości (zamiast być jednym i tym samym). Ten model domeny będzie zawierał właściwości i metodę logiki biznesowej.

Ale teraz te Modele Domen są nadal za usługą, a aby wystawić je na działanie świata zewnętrznego, musimy przekonwertować je na DTO.

Robimy tutaj manny mapowania.

Trwałość modelu domenyAby przekonwertować model domeny na DTO, aby przekazać między usługami

Nie kończy się to, ponieważ DTO może wymagać mapowania do ViewModel.

Wszystko to i problem powielania logiki walidacji nadal nie zniknęły, ponieważ klient chce walidacji w czasie rzeczywistym. ViewModel nie wie nic o walidacji, więc na przykład w SPA musisz ponownie przepisać logikę walidacji po stronie klienta (zwykle w javascript).

Również usługi są z natury bezstanowe (zorientowane na wiadomości lub RPC), więc wykonujemy wszystkie te mapowania, między Trwałością, a OO, a następnie z powrotem do Proceduralnego, na jakie korzyści? W jaki sposób uzasadniałbyś koszty pod względem praktycznym większości budżetu IT?

Rozumiem, że posiadanie pełnego DDD, z Agregowanymi Korzeniami, Modelami Domen itd. Byłoby „fajne”, ale jak można uzasadnić koszt i uderzenie w wydajność dev?

anti-pattern (lub antipattern) to wzorzec stosowany w operacjach społecznych lub biznesowych lub inżynierii oprogramowania, które mogą być powszechnie stosowane, ale są nieskuteczne i / lub przynoszą efekt przeciwny do zamierzonego w praktyce

A jeśli tak, to czy DDD i Rich Domain Model nie pasowałyby do powyższej definicji anty-wzorca niż „Lean” Domain Model. Przepraszam, gardzę załadowanym słowem „Anemiczny”.

Utrzymując Model Domeny „Lean”, pozwalasz na jego udostępnianie bez naruszania „zasady abstrakcyjnej zależności”, „Nie powtarzaj siebie” i czasochłonnego, żmudnego i podatnego na błędy procesu mapowania jednego nośnika danych na inny, i niezależnie od tego, co wiąże się z Testem Jednostkowym, który się nie kończy (chyba że myślisz o mapowaniu bez testów jednostkowych i masz nadzieję na najlepsze).