Anemic domain model to antywzorzec?

(Anty)wzorce projektowe <- tutaj jest, że anemic domain model to antywzorzec.

Przyznam, że jestem trochę zdziwiony, głównie dlatego, że chyba ostatnio czytałem coś przeciwnego.

Czy nie jest tak, że w ostatnich latach na fali krytyki OOP wypłynął nacisk na to, by jednak trzymać dane i operacje oddzielnie? Co w językach tradycyjnie obiektowych jak C# i Java sprowadza się do podziału klas na worki na dane, pozbawione logiki (czy nie m.in. w celu ułatwienia tego zostały wprowadzone rekordy do C#?) i klasy zawierające metody, ale same nie trzymające danych w inny sposób, jak poprzez operowanie na tych workach na dane. Czyli - o ile rozumiem - dokładnie anemic domain model?

Zdaje się, że to podejście jest też integralną częścią wielu "uznanych", szeroko wykorzystywanych wzorców, takich jak ECS? (Entity Component System - nawet w nazwie już jest wyraźnie zaznaczony podział na worki na dane i logikę)

Nie oznacza to, że trzymanie logiki w klasach (zamiast podejścia proceduralnego, sprowadzającego się do spamowania słowem kluczowym static) nie wnosi żadnych korzyści: można np. stosować DI oraz budować większą funkcjonalność z mniejszych klocków za pomocą kompozycji (czy nawet - tfu tfu - dziedziczenia)?

Anemic domain model to był raczej standard w Javie EE, gdzie był podział na serwisy i encje. Co ciekawe mimo że prawie jażdy model w Javie EE był anemiczny to słowo static nie było często używane a DI było stosowane. Taka magia EJB i Springa

IMHO o Anemic domain model najwięcej krzyczą fanatycy DDD :P
W językach nieobiektowych jak Haskell i Rust to anemiczny model jest standardem. Raczej trudno zrobić inaczej :D
BTW ciekawe jak jest w Go? Też model anemiczny?

(czy nie m.in. w celu ułatwienia tego zostały wprowadzone rekordy do C#?)

Rekordy są od takich rzeczy jak np. DTO w REST API. Istnienie DTO w projekcie nijak ma się do rich domain model, może być projekt oparty o DDD i mieć rekordy żeby eksportować dane do CSV czy przesyłać przez API restowe.

rekord lepiej się nadaje do worków na dane niż "zwykła" klasa, szczególnie, jeśli ten "worek na dane" ma być immutable?

Tak (no chyba że z jakiegoś chorego powodu potrzebujesz beanów z klasycznymi getterami)

a w anemic domain model worków na dane ma być na kopy

Podobnie jak @scibi_92 nie rozumiem :(

Anemiczny model przydaje się tam gdzie model jest naprawdę anemiczny, czyli np. CRUD. Drugim miejscem, gdzie anemiczny model się sprawdza to komunikacja międzyprocesowa, czyli np. jsony i reprezentowane przez DTOsy.
Generalnie struktury danych używane wewnątrz aplikacji powinny być "grube", bo to ułatwia rozumowanie o kodzie i minimalizuje szansę na zepsucie czegoś. Odwrotna sytuacja jest w komunikacji międzyprocesowej: tam chcemy, żeby danie były "głupie" bo to rozluźnia kontrakt i pozwala na łatwy rozwój kodu po obu stronach. Przykładem niech będzie protobuf, gdzie nie masz pól required a wartość opcjonalna jest implementowana tak samo jak tablica mająca długość 0 lub 1. Głupie, wymaga dużo walidacji, ale zyskujemy ogromny decoupling

W językach nieobiektowych jak Haskell i Rust to anemiczny model jest standardem. Raczej trudno zrobić inaczej :D

@KamilAdam trochę nie kupuję tego. Co prawda droga do osiągnięcia zalet "grubego" modelu jest inna, ale generalnie chodzi o to samo. Czytałem kiedyś "Functional Programming for mortals with scalaz" i z tego co widziałem to traktowanie inwariantów i implementowanie tego co można robić ze strukturą było dużo bardziej po tej "grubej" stronie

Anemic domain model to antywzorzec w kontekście aplikacji z logiką biznesową - wówczas logika dotycząca encji X jest rozmasowana po całym systemie, co prowadzi do duplikacji, a czasem nawet sprzeczności.

slsy napisał(a):

@KamilAdam trochę nie kupuję tego. Co prawda droga do osiągnięcia zalet "grubego" modelu jest inna, ale generalnie chodzi o to samo. Czytałem kiedyś "Functional Programming for mortals with scalaz" i z tego co widziałem to traktowanie inwariantów i implementowanie tego co można robić ze strukturą było dużo bardziej po tej "grubej" stronie

Konkretnie która strona?

IHMO "Rekord" dalej pozostaje "rekordem", niezależnie od tego ile sobie TypeClass/Traitów dla niego nie zaimplementujesz.
W Haskellu (i Scali) możesz mieć rekord w jednym pliku, TypeClassę (Interface) w drugim pliku, a implementację TypeClassy jeszcze w trzecim pliku (chociaż to podeście w Haskellu jest powoli tępione). Średnio mi to wygląda na nieanemiczny model :P

KamilAdam napisał(a):

IMHO o Anemic domain model najwięcej krzyczą fanatycy DDD :P
W językach nieobiektowych jak Haskell i Rust to anemiczny model jest standardem. Raczej trudno zrobić inaczej :D
BTW ciekawe jak jest w Go? Też model anemiczny?

Anemiczny model w ogóle nie dotyczy nie-OOP. Mówimy o językach, które wspierają obiektowość, czyli związanie danych i zachowań, a ludzie na złość z tego nie korzystają.
Największym kuriozum jest DDD, które jest wskroś obiektowe, z anemicznym modelem i milionami serwisów.

Saalin napisał(a):

Największym kuriozum jest DDD, które jest wskroś obiektowe, z anemicznym modelem i milionami serwisów.

No to chyba nie zrozumiałem idei DDD (jest to wielce prawdopodobne), ale pamiętam że we wstępie do świętej księgi było jechanie po anemicznym modelu domeny nazywając takie programy "Skryptami tranzakcyjmyni". Idę po pismo i postaram się znaleźć ten fragment

Księga niebieska (Vernon). Strony 56 i dalsze w wydaniu polskojęzycznym mówią o tym czemu Anemiczny model dziedziny jest zły, a DDD jest dobre. Może od tego czasu DDD ewoluowało i teraz sytuacja się dowróciła ? (I anemiczny model dziedziny jest już dobry w DDD?) Książka jest jednak z 2013 roku

scibi_92 napisał(a):

Nie rozumiem Twojego komentarza.

Spróbuję wyrazić się jaśniej.

KamilAdam napisał(a):

rekord lepiej się nadaje do worków na dane niż "zwykła" klasa, szczególnie, jeśli ten "worek na dane" ma być immutable?

Tak (no chyba że z jakiegoś chorego powodu potrzebujesz beanów z klasycznymi getterami)

OK, czyli się zgadzamy (a już chciałem pisać długaśnego posta, dlaczego tak uważam)

a w anemic domain model worków na dane ma być na kopy

Podobnie jak @scibi_92 nie rozumiem :(

anemic domain model: odwrócenie OOP. Jak w OOP logika i dane żyją razem w jednej klasie, tak w anemic domain model mamy podział na klasy zawierające metody oraz na worki na dane. Stąd w anemic domain model worków na dane będzie wyraźnie więcej, niż w rich domain model.

scibi_92 napisał(a):

Rekordy są od takich rzeczy jak np. DTO w REST API. Istnienie DTO w projekcie nijak ma się do rich domain model, może być projekt oparty o DDD i mieć rekordy żeby eksportować dane do CSV czy przesyłać przez API restowe.

Tak jest, w rich domain model też będziemy mieć worki na dane, podałeś ich przykład. DTO będziemy spotykać zarówno w anemic, jak i w rich domain model. Ale oprócz tego w anemic domain model będziemy spotykać jeszcze więcej worków na dane.

Tak więc istnienie rekordów ułatwia anemic domain model.

Niezależnie od tego na inną okoliczność Microsoft napisał:

These features represented the first tentative steps toward supporting programming paradigms where data and functionality live apart.

Stąd wnoszę, że C# chce iść powoli w kierunku właśnie podziału na logikę i dane. Czyli anemic domain model?

No to mój wniosek:

Skoro w anemic domain model mamy więcej worków na dane, rekordy ułatwiają pisane worków na dane w porównaniu z tradycyjnymi klasami, C# w ogóle chce iść w kierunku podziału na logikę i dane, to czy jednym z celów wprowadzenia rekordów nie jest właśnie ułatwienie utrzymywania podziału na logikę i dane?

Anemic model powoduje dwa podstawowe problemy. Pierwszy, jak ktoś już wspomniał @Charles_Ray to rozrzucenie logiki biznesowej po różnych serwisach, co może potem utrudniać rozbudowę kodu i refactoring. Drugi problem, chyba poważniejszy, to możliwość wprowadzenia encji w niepoprawny stan, np. utworzenie użytkownika z pustym hasłem. Ktoś mógłby argumentować, że przecież takich rzeczy pilnują właśnie serwisy, ale problem w tym, że wtedy jesteśmy zdani na łaskę tego czy każdy kto używa danego modelu zatroszczy się o walidację danych i zrobi to za każdym razem kiedy będzie chciał zmienić jego stan. Np. załóżmy, że mamy encję User. W przypadku anemic zarówno kiedy tworzymy Usera i zmieniamy np. jego hasło, musimy zwalidować poprawność danych (np. długość i format hasła itp.) a w rich taka logika jest w encji i nie ma bata, żeby utworzyć Usera np. z pustym hasłem czy coś w tym stylu a gruby serwis zmienia się w cienkiego handlera, w którym tylko pobiera się z repo encje i wywołuję metodę na niej z odpowiednimi parametrami.

YetAnohterone napisał(a):

Tak więc istnienie rekordów ułatwia anemic domain model.

Ułatwia też wiele innych rzeczy, jak tworzenie DTO (czyli coś co jest poza domeną) czy VO, o których było w komentarzu o Monetary.

Sampeteq napisał(a):

Drugi problem, chyba poważniejszy, to możliwość wprowadzenia encji w niepoprawny stan, np. utworzenie użytkownika z pustym hasłem.

To standard w obiektach, które są od góry do dołu getterami/setterami. Nawet spotykałem się, że encja ma niepoprawny stan by design, bo niektóre pola w jednym kontekście są ustawione, a w drugim nie, ale utworzenie klas, które pasowałby kontekstowo to już byłby overengineering. Ludzie do tego stopnia są przesiąknięci syfem ADM, że jak widzą fragment logiki razem z danymi to od razu żądają wyniesienia tego do odrębnej klasy, utworzenia interfejsu i wstrzykiwania przez DI, bo tak przecież wygląda OOP i dobre praktyki. To już przykłady o kotkach i pieskach z książek są bardziej zbliżone do tego jak OOP miał wyglądać,

To jest podobny problem jak modelowanie domeny myśląc od razu o tabelach w SQL. To, że tak najczęściej ludzie robią nie oznacza, że jest to dobre.

Jak się robi OOP, to ADM jest antywzorcem. Jak się nie robi OOP, to nie jest antywzorcem.
Z faktu, że używa się języka wspierającego paradygmat OOP nie wynika, że robi się OOP.
Przecież nawet w definicji "wzorca" jest podane, że zależy on od kontekstu, nie można powiedzieć, że coś jest wzorcem/antywzorcem zawsze i bezwzględnie. Jak ktoś tak mówi, to podchodzi do problemu dogmatycznie, a z tego zazwyczaj nic dobrego nie wychodzi.