Temat: (Anemiczny) Model Dziedziny

Temat wraca w moich rozważaniach niczym bumerang i postanowiłem zasięgnąć języka. Fowler opisał go dość jasno jako model statyczny (nie zawierający elementów dynamiki systemu). Upraszczając - klasy bez operacji są złe. No właśnie - klasy bez operacji, czy model bez operacji?
Weźmy sobie na warsztat prosty case - system do rejestrowana poczty przychodzącej i wychodzącej. Rozważmy trzy wersje "modelu dziedziny":
Wersja 1:



Wersja 2:



Wersja 3:



W zasadzie każda z nich pokazuje to samo. Zwróćmy jednak uwagę, że Wersja 2 jest stosunkowo bliska konstrukcyjnie wielu frameworkom MVC i pokrewnym.
Wersja 3 z kolei od 2 różni się tym, że wycięta została cała warswa dynamiki - czyli wróciliśmy do anemicznego modelu. W związku z tym także wersja 2 implementuje anemiczny model dziedziny. Tylko czy to tak bardzo źle?
Podstawą większości systemów dla biznesu jest zarządzanie dokumentami. Jest to z natury bardzo anemiczna sprawa - dokument można stworzyć, zmienić, usunąć, wyświetlić, znaleźć i udostępnić. W zasadzie sama istota dokumentu na tym się kończy - cała reszta to implikacje jakie dla biznesu ma pojawienie się takiego dokumentu.
Wroćmy do podstaw i funkcjonowania bez systemów IT. Weźmy zapytanie ofertowe

Od: ACME Sp z o.o.
Do: Hurt Sp z o.o.
Zapraszamy do złożenia oferty na dostawę
Produktu o nr kat ABC/1 w ilości 30 szt.
Produktu o nr kat XFD/2 w ilości 40 szt.

Niech obsługa takiego zapytania ofertowego polega na sprawdzeniu stanów magazynowych i jeśli mamy dostępne odpowiednie ilości - składamy ofertę z założoną marżą, jeśli nie mamy - nie składamy.
Reprezentując działanie firmy w oprogramowaniu stworzylibysmy dwa rejestry - Zapytań Ofertowych oraz Ofert umożliwiając użytkownikom zarządzanie obiektami zapytań oraz ofert. Ta dziedzina ze swej natury jest poprostu anemiczna(!).
Załóżmy, że chcielibyśmy zoptymalizować działąnie firmy i w przypadku tak prostej obsługi udzielać automatycznie odpowiedzi - czyli tworzyć automatycznie oferty. Innymi słowy chcemy zaimplementować funkcjonalność "Pani Kazia - Account Manager" - która czyta zapytania ofertowe i dla każdego sprawdza czy na stanach magazynowych są niezbędne produkty czy nie - jeśli są, składa ofertę, jeśli nie opdowiada że niestety nie złożymy oferty.
Teraz mamy dylemat - anemicznie czy nie?
Droga I:
Tworzymy sobie observer, który w przypadku pojawienia się zapytania ofertowego iteruje się po jego pozycjach i uruchamia metodę czyDostępny(nr_kat_produktu,ilosc) w naszym systemie magazynowym; jeśli każda pozycja jest dostępna tworzy dokument oferta wskazując cenę każdej z pozycji wyliczając ją jako iloczyn ceny zakupu i zakładanego narzutu, jeśli którejkolwiek pozycji jest brak tworzy odpowiedź na ofertę o treści "Sorry, nie składamy oferty".
UWAGA:
Przecież to wciąż anemiczny model dziedziny.
Droga II:
OOAD ponad wszystko. Dynamizujemy nasz model i już w klasie reprezentującej pozycję z zapytania ofertowego implementujemy metode weryfikującą dostępnośc na magazynie.
--
Argumenty za Drogą I:
- gotowość na zmiany - jeśli będziemy stosowali architekturę jak w v2 to zmiana konstrukcji któregokolwiek elementu wymusi na nas tylko aktualizacje interfejsów - a nie wybebeszanie połowy aplikacji
- rozszerzalność - załóżmy, że chcemy rozszerzyć kompetencjie Pani Kazi i pozwolić jej składać oferty częściowe - w przypadku Drogi I zmieniamy tylko jeden obszar - otóż jak nam się brakuje produktu tworzymy ofertę niepełną zamiast przerywać weryfikację; w przypadku Drogi II będzie to daleko bardziej skomplikowane
- adekwatność - oprogramowanie jest pewnego rodzaju modelem rzeczywistości a ten winien w danej perspektywie i na przyjętym poziomie abstrakcji być analogiczny do rzeczywistości i ten aspekt chciałbym rozwinąć. W tym artykule: http://maciuch-on-software.blogspot.com/2009/03/grasp-... znajduje się całkiem zgrabny przykład refaktoringu od anemicznego modelu dziedziny do dynamicznego. Powiedzcie mi jednak - czy ktoś z Was kiedykolwiek widział, żeby pozycja faktury liczyła swój rabat? Albo kartka z fakturą dopisywała sobie pozycje? Normalnie w rzeczywistości robi to np. fakturzysta. Autor twierdzi, że w ten sposób zmniejsza liczbę zależności - ale czy rzeczywiście?
Weźmy także pod uwagę, że separacja dynamiki od danych - pozwala nam na persystencję znaczną automatyzację persystencji danych i uniezależnienie się od jej sposobu (stosunkowo prosto zmienić nam bazę danych, czy nawet ORM-a).
O co więc tak naprawdę chodzi z tym anemicznym modelem dziedziny? Ja rozumiem, że modelowanie obiektowe to nie tylko struktury danych - ale czy koniecnzie oznacza to pakowanie operacji i atrybutow w jedną klasę?Ten post został edytowany przez Autora dnia 22.12.13 o godzinie 20:07

Temat: (Anemiczny) Model Dziedziny

Mateusz K.:
Temat wraca w moich rozważaniach niczym bumerang i postanowiłem zasięgnąć języka. Fowler opisał go dość jasno jako model statyczny (nie zawierający elementów dynamiki systemu). Upraszczając - klasy bez operacji są złe. No właśnie - klasy bez operacji, czy model bez operacji?

A model bez operacji można nazwać modelem dziedziny? ;-)

W tym artykule: http://maciuch-on-software.blogspot.com/2009/03/grasp-... znajduje się całkiem zgrabny przykład refaktoringu od anemicznego modelu dziedziny do dynamicznego.

Wniosek autora "anemiczny model to nie jest programowanie obiektowe" jak dla mnie przywołuje komentarz, oczywiście, bo modelowanie to nie programowanie. Tak samo jak analiza biznesowa to nie programowanie. Cóż, zarówno ta wypowiedź, jak i inne, sugerują, że "prawdziwe" DDD, DDD to które reprezentuje OOP, to tworzenie oprogramowania bez anemicznego modelu dziedziny. Absolutnie nie zgadzam się z takim podejściem. Anemiczny model dziedziny jest potrzebny, przydatny a DDD czy OOP to inne zagadnienie. ;-(

O co więc tak naprawdę chodzi z tym anemicznym modelem dziedziny?

Jak dla mnie nie pasuje on do podejścia, w ramach którego model dziedziny bezpośrednio "tłumaczony" jest na aplikację biznesową. OK, zgoda bo aplikacja biznesowa to nie tylko struktury danych ale i algorytmy. Ale jest jedno ale: model biznesowy można przenieść wprost na program tylko w przypadku niewielkich aplikacji. Twierdzenie anemiczny model dziedziny jest antywzorcem w tym kontekście jest prawdziwe.

W przypadku dużych aplikacji, aplikacji integrujących pracę różnych jednostek organizacyjnych firm, nie istnieje jeden spójny model biznesowy lecz jest on sumą modeli procesów. A rzeczywiste modele biznesowe procesów mają tę cechę, że wymagają jednoczesnego posługiwania się wzajemnie sprzecznymi tak strukturami (entity - value) jak i regułami (A -> B, B -> A ale jednocześnie A != B, itp, itd.). Powyższe sprawia. że podejście wyrażające się w opinii, że anemiczny model dziedziny jest antywzorcem i z tego powodu nie należy go stosować, a ci którzy tego nie rozumieją powinni dać sobie spokój z programowaniem bo anemiczny model to nie jest programowanie obiektowe, jawi się jako kij który ma dwa końce i pokazuje absurdalność takiego ortodoksyjnego myślenia. Bzdu-ra! :-(

Zmierzenie się z aplikacją zintegrowaną udowadnia to co już podkreśliłem: modelowanie to nie programowanie, tak samo jak analiza biznesowa to nie programowanie! W tym przypadku nie ma innej drogi jak rozdzielenie logiki biznesowej od struktur danych, a posłużenie się anemicznym modelem dziedziny porządkuje tak wiele, jak dla mnie, że warto taki model wykonać. ;-) Dwóch analityków: biznesu klienta i developera w tym przypadku opracowuje dwa różne modele i nie ma nic dziwnego jeżeli ten drugi z anemicznym modelem dziedziny się zaprzyjaźni. Sugerowanie, że on to pewnie przyzwyczajony do tradycji, że nie rozumie DDD czy OOP, że oporny, .. nadużyciem.

Ja rozumiem, że modelowanie obiektowe to nie tylko struktury danych - ale czy koniecnzie oznacza to pakowanie operacji i atrybutow w jedną klasę?

A wystarczy jak zapakujemy to w jeden obiekt? ;-)

Temat: (Anemiczny) Model Dziedziny

Mateusz K.:
Temat wraca w moich rozważaniach niczym bumerang i postanowiłem zasięgnąć języka. Fowler opisał go dość jasno jako model statyczny (nie zawierający elementów dynamiki systemu).

Strasznie dużo napisałeś :), ode mnie to:

"anemiczny" to klasy bez operacji, co w zasadzie sprowadza taki model do koncepcyjnego modelu danych. Nie będe tu mieszał ani DDD zaś MVC traktuje tu tak, ze interesuje mnie wyłącznie Model.

Problem anemicznego modelu to po prostu i aż, "niepotrzebne" oddzielenie tego co klasa wie od tego jak udostępnia swoją wiedzę. Ortodoksyjne podejście zakłada, że wszystkie atrybuty są chronione a ich wydobycie jest możliwe wyłącznie operacją. Tu ewentualnie można się po-wyżywać na osławionych get/set (czyli jak tego nie robić :)).

Zwrócę uwagę, że tu jeszcze nie pisze o implementacji a o modelu.

Wracam do Twojego przykładu: w zasadzie każda klasa reprezentująca np. wpis do dziennika powinna mieć operację "udostępnij treść tego wpisu" czy z zasady (trzymając się zasad chronienia atrybutów) ma choć te jedną operację wiec już nie jest anemiczna. Do tego dodam, że mogą to być dwie operacje "udostępnij jako XML" albo "udostępnij jako pdf", taki wpis można gdzieś przesłać jako obiekt albo jako DTO (pamietamy, ze DTP nie jest elementem dziedzinowym a parametrem wywołania).

pomysł by klasa ta miała get/set dla każdego atrybutu jest masakryczny to tworzy złożony i interfejs, który będzie zmieniany jak tylko zmienimy pomysł na tę klasę i jej atrybuty. (to będzie strasznie niestabilny interfejs czyli łamiemy zasadę open-close principia).

Przy okazji: Wyszukaj (zakładam, że jakiś wpis) to raczej operacja (odpowiedzialność) Repozytorium a nie Zarządcy, który w tym kontekście wydaje mi się nadmiarowy. gdybym pakował takiego Zarządce do dziedziny to raczej nie do "wyszukiwania" a do realizacji logiki nie niezwiązanej z repozytorium (np. zmień status wpisu do dziennika po zakończeniu sprawy). Kolejna dobra praktyka w kwestii dokumentów: dokumenty są przetwarzane a nie "się przetwarzają".

Bardzo często spotykam się z traktowaniem modelu dziedziny łącznie z ORM (który np. odtwarza obiekty z zapisów w tablicach bazy danych co mylnie jest nazywane "Fabryką").


Tak więc coś (klasa) co nie ma żadnej operacji z zasady jest "sztuczne" bo skoro paradygmat obiektowy oznacza realizację działania poprzez wzajemne współdziałanie obiektów (one się wywołują) to obiekty bez operacji przestają być "obiektowe" w tym rozumieniu bo nie ma kogo wywoływać.

Temat: (Anemiczny) Model Dziedziny

Marek K.:
Wniosek autora "anemiczny model to nie jest programowanie obiektowe" jak dla mnie przywołuje komentarz, oczywiście, bo modelowanie to nie programowanie. Tak samo jak analiza biznesowa to nie programowanie. Cóż, zarówno ta wypowiedź, jak i inne, sugerują, że "prawdziwe" DDD, DDD to które reprezentuje OOP, to tworzenie oprogramowania bez anemicznego modelu dziedziny. Absolutnie nie zgadzam się z takim podejściem. Anemiczny model dziedziny jest potrzebny, przydatny a DDD czy OOP to inne zagadnienie. ;-(

Nie mieszajmy to DDD bo nie ma takiej potrzeby. Generalnie jest to moim zdaniem chyba daleko idące uproszczenie: łączy implementację (ta może mieć ograniczenia wynikające z użytego języka) z projektem. Otóż anemiczny model jest zły (niezgodny z paradygmatem i szkodliwy dla architektury całości), to implementacja i jej ograniczenia mogą prowadzić do skutku jakim jest anemiczny model (np. framework EJB, który z zasady operuje na anemicznym modelu).

Generalnie uważam, że jeżeli gdzieś jest potrzebny anemiczny model to jest to skutek narzędzi i metod użytych do implementacji a nie potrzeba, i jest to "świadome" psucie modelu "dobrego" tak samo jak np. denormalizacja bazy jest jej "psuciem" np. z powodu wymagań wydajnościowych.

Uważam, ze bardzo dobrą praktyką jest projektowanie "porządne" i zostawianie "psucia" developerowi po warunkiem że co najwyżej troszkę psuje a nie całkowicie niszczy projekt ;)))

O co więc tak naprawdę chodzi z tym anemicznym modelem dziedziny?

Jak dla mnie nie pasuje on do podejścia, w ramach którego model dziedziny bezpośrednio "tłumaczony" jest na aplikację biznesową. OK, zgoda bo aplikacja biznesowa to nie tylko struktury danych ale i algorytmy. Ale jest jedno ale: model biznesowy można przenieść wprost na program tylko w przypadku niewielkich aplikacji. Twierdzenie anemiczny model dziedziny jest antywzorcem w tym kontekście jest prawdziwe.

A ja uważam, że wielkość aplikacji nie ma tu nic do rzeczy z prostego powodu: i tak dzielimy ją (kolejna dobra praktyka) na "małe" komponenty...

W przypadku dużych aplikacji, aplikacji integrujących pracę różnych jednostek organizacyjnych firm, nie istnieje jeden spójny model biznesowy lecz jest on sumą modeli procesów. A rzeczywiste modele biznesowe procesów mają tę cechę, że wymagają jednoczesnego posługiwania się wzajemnie sprzecznymi tak strukturami (entity - value) jak i regułami (A -> B, B -> A ale jednocześnie A != B, itp, itd.). Powyższe sprawia. że podejście wyrażające się w opinii, że anemiczny model dziedziny jest antywzorcem i z tego powodu nie należy go stosować, a ci którzy tego nie rozumieją powinni dać sobie spokój z programowaniem bo anemiczny model to nie jest programowanie obiektowe, jawi się jako kij który ma dwa końce i pokazuje absurdalność takiego ortodoksyjnego myślenia. Bzdu-ra! :-(

albo nie rozumiem "przyczyny" sprzecznych struktur, albo przyczyną jest to, że ktoś chce je na siłę wpakować w jeden "spójny" model danych, co w dużych projektach faktycznie jest mało realne bez "psucia" (z czegoś trzeba rezygnować by uzyskać taką spójność całości). Klasyczny przykład takiego przegranego i głupiego boju jaki widziałem (po dwóch latach próby napisania tej aplikacji zrezygnowano i powstały dwie odrębne zintegrowane), to próba uzyskania spójności modelu danych opisujących środki trwałe jednocześnie i dla FK i na potrzeby zarządzania sprzętem rozstawionym po całej Polsce. To, bez szkody dla obu tych potrzeb, nie ma żadnych szans. A wystarczy dać sobie spokój ze spójnością całości, stworzyć dwa modele dziedzinowe czyli rozłączne komponenty (lub aplikacje), osobno na potrzeby FK i osobno na potrzeby zarządzania konfiguracją tych konstrukcji i ich położeniem geograficznym, remontami itp. Skojarzenie ich (integracja) jest prosta bo obiekt na polu i środek trwały do amortyzacji łączy numer środka trwałego.

Zmierzenie się z aplikacją zintegrowaną udowadnia to co już podkreśliłem: modelowanie to nie programowanie, tak samo jak analiza biznesowa to nie programowanie! W tym przypadku nie ma innej drogi jak rozdzielenie logiki biznesowej od struktur danych,

I ja zawsze w tym momencie dziękuję, bo jest inna droga i można projektować inaczej, w końcu od czasu do czasu coś wychodzi spod mojej ręki i działa (i to całkiem nieźle). Dodam, dla wyjaśnienia: to, że implementacja obiektowego projektu może wymagać (i wymaga) przyjęcia jakiejś implementacji utrwalania (np. w postaci jakiejś bazy), nie narzuca relacyjnej implementacji i nie narzuca obowiązku uspójniania danych. Można napisać bardzo fajny i bardzo duży system nie wbijając nawet żadnej logiki w bazy danych.

Tak więc nie rozumiem dlaczego "anemiczność" MUSI być, nie musi...

Temat: (Anemiczny) Model Dziedziny

Mateusz K.:

Od: ACME Sp z o.o.
Do: Hurt Sp z o.o.
Zapraszamy do złożenia oferty na dostawę
Produktu o nr kat ABC/1 w ilości 30 szt.
Produktu o nr kat XFD/2 w ilości 40 szt.

OOAD ponad wszystko. Dynamizujemy nasz model i już w klasie reprezentującej pozycję z zapytania ofertowego implementujemy metode weryfikującą dostępnośc na magazynie.

proszę Cie :) od kiedy to pozycja zapytania odpowiada za wiedzie o tym co w magazynie, nigdy :), za wiedzę o stan magazynu odpowiada wyłącznie komponent Magazyn a nie Ofertowanie ;), to faktycznie będzie masakryczne w utrzymaniu :D

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Czy słusznie wnioskuję więc, że Model Wersja 2 jest OK?

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Mateusz K.:

Od: ACME Sp z o.o.
Do: Hurt Sp z o.o.
Zapraszamy do złożenia oferty na dostawę
Produktu o nr kat ABC/1 w ilości 30 szt.
Produktu o nr kat XFD/2 w ilości 40 szt.

OOAD ponad wszystko. Dynamizujemy nasz model i już w klasie reprezentującej pozycję z zapytania ofertowego implementujemy metode weryfikującą dostępnośc na magazynie.

proszę Cie :) od kiedy to pozycja zapytania odpowiada za wiedzie o tym co w magazynie, nigdy :), za wiedzę o stan magazynu odpowiada wyłącznie komponent Magazyn a nie Ofertowanie ;), to faktycznie będzie masakryczne w utrzymaniu :D

Świetnie. Zabałaganiło mi w głosie http://maciuch-on-software.blogspot.com/2009/03/grasp-..., szczególnie że znalazłem w komentarzach Twój jak mniemam przychylny wpis. Natomiast to co ten człowiek tam robi to dla mnie lekka masakra - dlaczego klasa agregująca pozycje faktury ma metody od liczenia VAT:P

Temat: (Anemiczny) Model Dziedziny

Mateusz K.:
Świetnie. Zabałaganiło mi w głosie http://maciuch-on-software.blogspot.com/2009/03/grasp-..., szczególnie że znalazłem w komentarzach Twój jak mniemam przychylny wpis. Natomiast to co ten człowiek tam robi to dla mnie lekka masakra - dlaczego klasa agregująca pozycje faktury ma metody od liczenia VAT:P

ja go pochwaliłem za "krytykę anemii modelu", a nie za projekt, bo tu się z Tobą zgodzę, że to pomysł masakryczny ....

Temat: (Anemiczny) Model Dziedziny

Mateusz K.:

Jarosław Ż.:

Czy słusznie wnioskuję więc, że Model Wersja 2 jest OK?

najbliżej memu sercu :), ale nie rozumiem czemu wydzieliłeś tak boundary? Klasy usługowe to także logika domenowa...

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:
Anemiczny model dziedziny jest potrzebny, przydatny a DDD czy OOP to inne zagadnienie. ;-(

Nie mieszajmy to DDD bo nie ma takiej potrzeby.

OK

Otóż anemiczny model jest zły (niezgodny z paradygmatem i szkodliwy dla architektury całości), ..

Można poprosić o przykłady?

Generalnie uważam, że jeżeli gdzieś jest potrzebny anemiczny model to jest to skutek narzędzi i metod użytych do implementacji a nie potrzeba, i jest to "świadome" psucie modelu "dobrego" tak samo jak np. denormalizacja bazy jest jej "psuciem" np. z powodu wymagań wydajnościowych.

Uważam, ze bardzo dobrą praktyką jest projektowanie "porządne" i zostawianie "psucia" developerowi po warunkiem że co najwyżej troszkę psuje a nie całkowicie niszczy projekt ;)))

Ale przecież ta dobra praktyka projektowania rozpoczyna się od elementarnych struktur, które później są rozbudowywane, tak jak denormalizację poprzedza normalizacja, a nie odwrotnie, więc się pogubiłem w tym co jest psuciem, a co jest porządnym projektowaniem i komu przypisać odpowiedzialności za niniejsze, developerowi czy modelarzowi. ;-)

A ja uważam, że wielkość aplikacji nie ma tu nic do rzeczy z prostego powodu: i tak dzielimy ją (kolejna dobra praktyka) na "małe" komponenty...

Niestety ale nie wszystko da się podzielić na całkowicie niezależne, rozdzielne części i wielkość ma tu znaczenie. ;-(

W przypadku dużych aplikacji, aplikacji integrujących pracę różnych jednostek organizacyjnych firm, nie istnieje jeden spójny model biznesowy lecz jest on sumą modeli procesów. A rzeczywiste modele biznesowe procesów mają tę cechę, że wymagają jednoczesnego posługiwania się wzajemnie sprzecznymi tak strukturami (entity - value) jak i regułami (A -> B, B ->

albo nie rozumiem "przyczyny" sprzecznych struktur, albo przyczyną jest to, że ktoś chce je na siłę wpakować w jeden "spójny" model danych, co w dużych projektach faktycznie jest mało realne bez "psucia" (z czegoś trzeba rezygnować by uzyskać taką spójność całości).

Dokładnie to drugie. ;-(

To, bez szkody dla obu tych potrzeb, nie ma żadnych szans. A wystarczy dać sobie spokój ze spójnością całości, stworzyć dwa modele dziedzinowe czyli rozłączne komponenty (lub aplikacje),

Dokładnie. I dlatego też wcześniej protestowałem, kiedy wymienialiśmy sprzeczne poglądy na temat wymuszania na developerach używania narzuconego modelu, zamiast integracji bo rozłączne komponenty nie jest równoważne niezależne.

Zmierzenie się z aplikacją zintegrowaną udowadnia to co już podkreśliłem: modelowanie to nie programowanie, tak samo jak analiza biznesowa to nie programowanie! W tym przypadku nie ma innej drogi jak rozdzielenie logiki biznesowej od struktur danych,

I ja zawsze w tym momencie dziękuję, bo jest inna droga i można projektować inaczej, ..

??? Przecież przed chwilą było, że są rzeczy mało realne :-( więc się pogubiłem z tym łączeniem logiki biznesowej różnych modeli, które będą oczekiwały różnych struktur danych co jest niewykonalnym w jednym projekcie.

Tak więc nie rozumiem dlaczego "anemiczność" MUSI być, nie musi...

Anemiczność to fundament. Można inaczej? Oczywiście, np: w Katowicach wybudowano kiedyś "dom wypych", czyli najpierw "postawiono" najwyższe piętro (16?), a potem dokładano kążde następne aż do parteru, tylko po co? ;-)

Mateusz K.:
Natomiast to co ten człowiek tam robi to dla mnie lekka masakra - dlaczego klasa agregująca pozycje faktury ma metody od liczenia VAT:P

Zgadzam się, bo przecież VAT ustawodawca potrafił uzależnić także od klienta (osoba fizyczna / podmiot gospodarczy), rodzaju transakcji (import / eksport) czy też dokumentu (faktura wewnętrzna / ..), .. . :-( Ale nie powinniśmy tego traktować jako edukacyjny przykład, a nie "pracujące" rozwiązanie?

Temat: (Anemiczny) Model Dziedziny

Marek K.:

Otóż anemiczny model jest zły (niezgodny z paradygmatem i szkodliwy dla architektury całości), ..

Można poprosić o przykłady?

Przykłady czego, szkodliwości? To generalnie bardzo proste: jeżeli oddzielę "dane" od "ich logiki", czyli stworze aplikację z anemicznym modelem dziedziny, to:
- zarówno dane jak oddzielone od nich funkcje tracą swój kontekst z perspektywy "czytacza kodu lub projektu", im większy system tym trudniejszy staje się do "zrozumienia jako całość"
- każda funkcjonalność ma zamiast jednego (nieanemiczna klasa) miejsca w kodzie (projekcie) dwa do "zarządzania" (osobno część w jakimś sporym modelu danych osobno gdzieś jakaś funkcja, która tym zarządza). W miarę więc rozrostu system jego złożoność (liczba powiązań) bardzo szybko rośnie.

Niezgodności z paradygmatem nie komentuję bo jest chyba oczywista.

Ale przecież ta dobra praktyka projektowania rozpoczyna się od elementarnych struktur,

Struktur czego?

A ja uważam, że wielkość aplikacji nie ma tu nic do rzeczy z prostego powodu: i tak dzielimy ją (kolejna dobra praktyka) na "małe" komponenty...

Niestety ale nie wszystko da się podzielić na całkowicie niezależne, rozdzielne części i wielkość ma tu znaczenie. ;-(

no to mamy niezgodność doświadczeń :) bo ja podtrzymuje swoje zdanie, jak na razie nie trafiłem na nic czego nie da się podzielić :), może teraz ja poproszę o przykład?

albo nie rozumiem "przyczyny" sprzecznych struktur, albo przyczyną jest to, że ktoś chce je na siłę wpakować w jeden "spójny" model danych, co w dużych projektach faktycznie jest mało realne bez "psucia" (z czegoś trzeba rezygnować by uzyskać taką spójność całości).

Dokładnie to drugie. ;-(

Więc przyznaje Pan jednak, że jeden wielki model danych nie ma sensu ...

To, bez szkody dla obu tych potrzeb, nie ma żadnych szans. A wystarczy dać sobie spokój ze spójnością całości, stworzyć dwa modele dziedzinowe czyli rozłączne komponenty (lub aplikacje),

Dokładnie. I dlatego też wcześniej protestowałem, kiedy wymienialiśmy sprzeczne poglądy na temat wymuszania na developerach używania narzuconego modelu, zamiast integracji bo rozłączne komponenty nie jest równoważne niezależne.

Rozłączne są rozłączne tylko wtedy gdy są niezależne (każdy sam do czegoś służy - o ile się to z sensem projektuje). Co do narzucania czegoś developerowi to obstaje przy tym, i robię to bo to jedyna metoda zarządzania ryzykiem projektu. To ma bardzo proste "wytłumaczenie": z gustami się nie dyskutuje, po drugie jako projektant ja składam klientowi obietnicę a nie developer i ja decyduję o architekturze, więc developer jak mu się ona nie podoba po protu nie składa oferty. Nie ma chyba bardziej kretyńskiego podejścia w projektach niż "a ja bym to zrobił inaczej". Na takie dyskusje miejsce jest tu na forem, bo tu każdy by to zrobił inaczej, w projekcie wywalam takich.

Zmierzenie się z aplikacją zintegrowaną udowadnia to co już podkreśliłem: modelowanie to nie programowanie, tak samo jak analiza biznesowa to nie programowanie! W tym przypadku nie ma innej drogi jak rozdzielenie logiki biznesowej od struktur danych,

I ja zawsze w tym momencie dziękuję, bo jest inna droga i można projektować inaczej, ..

??? Przecież przed chwilą było, że są rzeczy mało realne :-( więc się pogubiłem z tym łączeniem logiki biznesowej różnych modeli, które będą oczekiwały różnych struktur danych co jest niewykonalnym w jednym projekcie.

:D Pan poczyta, proszę, jeszcze raz mój przykład o zbawiennym oddzieleniu modelu dla komponentu "środki trwałe" i komponentu "zarządzanie infrastrukturą". Kluczową różnica podejścia obiektowego i strukturalnego jest to, że strukturalne to "algorytmy + struktury danych = program" a obiektowe to "obiekty z zaszytą wiedzą (dane), współdziałając ze sobą realizują określone funkcje", dlatego w podejściu strukturalnym Pana problem sprzeczności będzie występował, a w obiektowym nie, ten drugi "struktury danych" hermetyzuje już na poziomie klasy i "nie widać" ich na zewnątrz więc nie mogę z sobą kolidować nie mając z sobą styku. Ja nie mam nigdy problemów które Pan opisuje...

Pytanie uzupełniające: czym dla Pana jest logika biznesowa, bo to jest zarówno reguła w rodzaju "dopuszczamy zbiorcze faktury dla wielu zamówień w miesiącu" (ta logika jest oddzielona od faktur i zamówień", stanowi element odrębnej klasy usługowej i nie jest to ani faktura ani zamówienie), zaś logika biznesowa "data faktury nie może poprzedzać daty sprzedaży" jest związana z klasą FakturaVAT. O której logice Pan pisze?

Anemiczność to fundament.

a wystarczyło napisać to zdanie na początku i ja wtedy grzecznie powiem "z gustami się nie dyskutuje" i nie ma w tym nic złego. Ja wiem, ze powstają systemy o różnych architekturach. Dla mnie, reprezentuję stronę kupującego, liczą się zawsze łącznie:
- koszty dostarczenia/wytworzenia systemu
- w długim horyzoncie czasu koszty utrzymania i rozwoju

a obecnie niestety dużym utrudnieniem jest duża zmienność środowiska i wymagań i budowanie "jednolitych struktura danych" dla dużych systemów jest.... uciążliwe bo ich modyfikacja w żywym systemie jest ... uciążliwa, mają zdrowy a nie anemiczny model dziedziny dużego systemu (a w zasadzie lokalne modele dla komponentów) ten problem nie występuje ... ale podkreślam: traktuje to jako wymianę doświadczeń a spór ideologiczny, z których dawno wyrosłem.

Dla mnie zawsze wyznacznikiem będzie cena: co ciekawe, ja zawsze jestem w stanie podać przybliżoną cenę wytworzenia w przyszłości nowej funkcjonalności nie mając nawet pojęcia czego będzie dotyczyła :) i jestem na tyle "wredny", że żądam tego od projektantów (gdy sam nim nie jestem). Bo kolejna dobra praktyka OOAD to: dobrze zaprojektowany system jest "otwarty na rozszerzenia i zamknięty na zmiany". Ten post został edytowany przez Autora dnia 01.02.14 o godzinie 11:07

Temat: (Anemiczny) Model Dziedziny

Panie Marku, moja prośba, proszę może nie odpowiadać na powyższy dość długi mój post bo to wymiana ideologiczna ;)., proszę odpowiedź może na to:

Prosty przykład i standardowy problem jaki mi się nasunął i pytanie: jak wykonać prosty anemiczny (jeden, spójny i niesprzeczny) model dla sytuacji w której mam rejestr faktur i rejestr kontrahentów, gdzie kontrahenci zmieniają czasem np. adres siedziby co nie może się przenieść na historyczne faktury (są tam te adresy).

powyższe pytanie do wszystkich :), bo w tak zwanym paradygmacie obiektowym to jest pikuś ;) Ten post został edytowany przez Autora dnia 01.02.14 o godzinie 14:14

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

a obecnie niestety dużym utrudnieniem jest duża zmienność środowiska i wymagań

Nie rozumiem dlaczego niestety ? :)
To chyba zależy od miejsca "siedzenia" uczestnika tego biznesu.

Temat: (Anemiczny) Model Dziedziny

Piotr B.:

Jarosław Ż.:
a obecnie niestety dużym utrudnieniem jest duża zmienność środowiska i wymagań

Nie rozumiem dlaczego niestety ? :)
To chyba zależy od miejsca "siedzenia" uczestnika tego biznesu.

hm... jeżeli miałeś na myśli "kosztowny w utrzymaniu system jest dobry dla developera bo daje mu dodatkowe zyski" to już Cie nie lubię ;)), dwa: niektórzy developerzy uważają, że to wymaga częstych zmian w "bazach danych" a to jest trudne :) to wtedy oni maja problem a nie ja...;) Ten post został edytowany przez Autora dnia 02.02.14 o godzinie 09:42

Temat: (Anemiczny) Model Dziedziny

z powodu czujności analitycznej :) poszperałem w tak zwanej literaturze (czyli nie w sieci a w książkach ;P) i:

skoro paradygmat obiektowy to uznanie, że "system składa się ze współpracujących ze sobą obiektów, celem tej współpracy jest realizowanie określonych funkcji", zaś współpraca pomiędzy obiektami to ich wzajemne wywołania, to znaczy że "model anemiczny" (klasy bez operacji) z zasady nie jest modelem obiektowym :)

tak więc zdanie "anemiczny model dziedziny" w odniesieniu do "metod obiektowych" to oksymoron..

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:
Prosty przykład i standardowy problem jaki mi się nasunął i pytanie: jak wykonać prosty anemiczny (jeden, spójny i niesprzeczny) model dla sytuacji w której mam rejestr faktur i rejestr kontrahentów, gdzie kontrahenci zmieniają czasem np. adres siedziby co nie może się przenieść na historyczne faktury (są tam te adresy).

powyższe pytanie do wszystkich :), bo w tak zwanym paradygmacie obiektowym to jest pikuś ;)

Jestem w rozjazdach więc przepraszam że nie odpowiedziałem od razu.

Osobiście nie widzę różnicy w trudności rozwiązania obiektowo / nieobiektowo bo sedno problemu skupia się na logice biznesowej.

Podany przykład to pytanie o to jak reprrejestrować w bazie dane zależne od czasu czyli to pytanie o 6NF. Odpowiedź jest jedną. Tak jak przewiduje model. I tu jest pies pogrzebany bo co jest refundacją a co nie jest decyduje logika. A logika w tym elemencie jest pochodną oczekiwań użytkowników. Użytkownicy natomiast najchętniej nie spełniali by wymagań prawnych argumentując niezyciowoscia usztywnień.

Jak? Zgodnie z modelem. W moim podejsciu wystawiony dokument nie burzy anemicznego modelu bo to co innego (logika) niż dane o kontrahentami czy towarach.

Moje przemyślenia w tym zakresie wiążą się z potrzebą wymuszenia proceduralnych postępowania i

Temat: (Anemiczny) Model Dziedziny

Marek K.:
Podany przykład to pytanie o to jak reprrejestrować w bazie dane zależne od czasu czyli to pytanie o 6NF. Odpowiedź jest jedną. Tak jak przewiduje model.

jest więcej niż jedne model: jeden z nich to model relacyjny... więc jak - poproszę o prosty obrazek np. ERD, Pan proponuje?

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:
Podany przykład to pytanie o to jak reprrejestrować w bazie dane zależne od czasu czyli to pytanie o 6NF. Odpowiedź jest jedną. Tak jak przewiduje model.

jest więcej niż jedne model: jeden z nich to model relacyjny... więc jak - poproszę o prosty obrazek np. ERD, Pan proponuje?

Model biznesowy mam na myśli a ten odwołuje się do procesów. Relacji w to nie mieszajmy bo "psucie" dotyczy tegoao w tabelach a nie relacji jakie je wiążą.

Jeżeli procesów jest więcej niż jeden to potrzebny kompromis i wybór (logika). Decyduje pragmatyka.

Temat: (Anemiczny) Model Dziedziny

Marek K.:
Jeżeli procesów jest więcej niż jeden to potrzebny kompromis i wybór (logika). Decyduje pragmatyka.

I jakich procesach mowa? Tych biznesowych czy tych zachodzących wewnątrz oprogramowania?

Po drugie: Klient nie chce kompromisów...

Temat: (Anemiczny) Model Dziedziny

Jarosław Ż.:

Marek K.:
Jeżeli procesów jest więcej niż jeden to potrzebny kompromis i wybór (logika). Decyduje pragmatyka.

I jakich procesach mowa? Tych biznesowych czy tych zachodzących wewnątrz oprogramowania?

Biznesowych

Po drugie: Klient nie chce kompromisów...

To zadanie modelarza. Dylemat czy anemiczny model jest be to problem developera i ja w tym kontekście. Ponadto
Wątpliwości czy anemiczny model jest modelem obiektowym to false dilema. To ma się nijak czy programujemy oop bo me czego są klasy abstrakcyjne i modele wielowarstwowe?