Komentarze do: Anemic Domain Model vs Rich Domain Model – Co to❔❓

Autor: Domino

Domino — Sun, 10 Sep 2023 16:09:25 +0000

Bardzo fajny artukuł, dzieki! Szkoda tylko, że RDM jest tak bagatelizowany, programuje od kilku lat i w każdym projekcie sytuacja była podobna, klasa posiada pola, gettery i settery a logika biznesowa roproszona po różnych klasach typu service, helper itd.

Autor: Bartosz Dąbek

Bartosz Dąbek — Tue, 30 Nov 2021 09:30:06 +0000

W odpowiedzi do Mati cwaniak. Niestety, ale z biegiem czasu co raz bardziej się przekonuję, że jest tak jak piszesz. Oczywiście zmiany zaczynają się od nas - więc jak chcemy coś zmienić to musimy wychodzić z inicjatywą. Pytanie tylko czy warto.

Autor: Mati cwaniak

Mati cwaniak — Tue, 30 Nov 2021 09:17:12 +0000

Cześć,
Rich Domain Model to czyste zło! Po pierwsze w RDM metody, które operują na danym obiekcie znajdują się wewnątrz tego obiektu. Powoduje to, że juniorom, bądź nowym członkom projektu łatwiej znaleźć zaimplementowane już funkcje (ponieważ są zdefiniowane w jednym miejscu). Jest to bardzo niekorzystne zjawisko, ponieważ wiadomo, że nowi programiści powinni najpierw przeiterować po całej warstwie serwisów (w większych projektach są to nawet setki klas) żeby sprawdzić, czy funkcjonalność, której akurat potrzeba nie została już zaimplementowana wcześniej. Najczęściej jednak źli programiści, nie wiedzieć czemu (może dziwnie implementować 1 mały ficzer przez tydzień?), nie chcą ogarnąć kodu całej aplikacji, żeby zrobić zmianę w jednym miejscu i duplikują zaimplementowane już zachowania tworząc je np. w nowych serwisach. To powoduje, że serwisów jest jeszcze więcej i iteracja po nich jest coraz trudniejsza i… you see where it goes. Także, ADM powoduje, że kod staje się trudniejszy w utrzymaniu, bardziej skomplikowany i próg wejścia w projekt staje się bardzo wysoki. To dobrze, bo to gwarantuje developerowi/developerom odpowiedzialnym za powstały bajzel pozycję w firmie (przecież nie zwolnimy jedynej osoby, która potrafi ogarnąć swój bajzel). Dzięki temu można potem negocjować wyższe stawki itp. Niestety taki stan rzeczy nie może trwać w nieskończoność. Zabawa kończy się kiedy stan obiektów na których pracujemy wpada w nieprzewidziany stan, bo coś, gdzieś, w pewnym momencie je modyfikuje i już nawet sam autor tego monumentu spaghetti nie wie gdzie leży tego przyczyna (na pewno nie w braku hermetyzacji). Wtedy oczywiście trzeba zwalić winę na wszystko inne, tylko nie na złą architekturę, a już na samym końcu, gdy implementacja czegokolwiek i utrzymanie projektu jest porównywalne tylko z wojną w Wietnamie, można najzwyczajniej zmienić pracę.
Powyższy wpis niestety, choć podkolorowany i przejaskrawiony, jest inspirowany rzeczywistością. Na studiach nauczyłem się czym jest OOP, czym różni się od programowania strukturalnego i dlaczego to drugie zostało ostatecznie wyparte przez obiektowość. W pracy jednak trafiłem na gości, dla których jedynym słusznym sposobem na projektowanie jest Anemic Domain Model. Zwracanie uwagi na problemy jakie się za tym ciągną nie dało nic. ADM broniony był przez autorytet seniorów, z których jeden się zwolnił, a drugi trafił do innego projektu. Ich dzieło było jeszcze chwile utrzymywane przez parę innych osób po czym ostatecznie projekt upadł.
No cóż, dużo mnie to nauczyło. Wystarczy dostarczyć kod, który działa (do pewnego czasu), a jego jakość nie ma znaczenia. Ważne, by być pewnym siebie i dobrze sprzedawać managementowi swoje genialne, potwierdzone doświadczeniem pomysły.
Kiedyś uważałem, że trzeba mieć wiedze, żeby być seniorem, teraz uważam, że seniorem się jest po to, żeby tej wiedzy nie musieć posiadać 🙁
[Powyżej moja subiektywna opinia, dystans zalecany, nie bierzcie tego zbytnio do siebie ;)]

Autor: Bartosz Dąbek

Bartosz Dąbek — Fri, 24 Jul 2020 07:58:14 +0000

W odpowiedzi do 0xmarcin. Hej, po pierwsze, dzięki za komentarz. Sprawdzę na czym polega to podejście, które promuje Jimmy. Wydaje się, że ta prezentacja z 2018 będzie do tego dobrym wstępem. A prezentację o której wspomniałeś na konferencji BuildStuff w Wilnie można znaleźć tutaj (zgaduję na 99%, że to jest to).

Autor: 0xmarcin

0xmarcin — Fri, 24 Jul 2020 07:07:08 +0000

Bardzo dobry wpis, gratulacje!

Chciałbym dodać od siebie że model „anemiczny” vs domenowy to fałszywa dychotomia.

Istnieje wiele podejść pomiędzy, np. jednym z moich ulubionych jest podejście promowane przez Jimmiego Bogarta (https://jimmybogard.com/) będące w duzym uproszczeniu połączeniem CQS (Command query separation – nie mylić z CQRS) z modelem anemicznym.

Cechy szczególne tego podejścia to podział serwisów na command i query handlery. Uzycie wzorca mediator do wywolania odpowiedniego command handlera gdy posiadamy obiekt komendy. Uzycie event publishera i event handlerow do obslugi efektow „pobocznych”. Operowanie bezposredion na encjach w command handlerach. I na koniec testowanie głównie na poziomie command handlerów (niektórzy mówią integracyjne z prawdziwą DB, ale ja się z tym nie zgadzam).

Podejscie to jest niestety niezbyt znane w swiecie JVMowym byc moze dlatego ze pan Bogart pracuje glownie z .NETem. Bogarta mozna było spotkac w ubiegłym roku na konferencji BuildStuff w Wilnie (polecam), gdzie miał prezentację na temat tego podejścia.

Jest tez cały świat programowania funkcyjnego, gdzie ścierają się rózne podejscia do enkapsulacji. Moje osobiste zdanie jest takie ze enkapsulacja to dobra rzecz nie wazne czy piszę obiektowo czy funkcyjnie. Sporo osob ma jednak inne zdanie i uwaza ze program powinien operowac na „nagich danych”. Immutowalność uprawsza tutaj wiele rzeczy.