Domain Model – serce aplikacji

Wstęp

Całkiem niedawno pisałem o tworzeniu diagramów klas a konkretnie modelu dziedziny  w odpowiedzi na post pewnego blogera. Wymiana poglądów skończyła się ze strony adwersarza na zwróceniu uwagi, iż diagram klas może pokazywać więcej niż mój (bo może) ja zaś zwróciłem uwagę na fakt, że diagram klas to nie jakiś model a model powinien modelować jedne coś. Pokazanie na jednym diagramie klas dużo raczej mija się z celem, bo można zabrnąć w rejon gdzie sprawdza się reklama Banki od wszystkiego są do niczego. Tak więc nie należy przeciążać diagramów.

Model dziedziny systemu to model mechanizmu jego działania

The Domain Model is an object model of the domain that incorporates both behavior and data. [Model Dziedziny jest obiektowym modelem dziedziny, który zawiera zarówno zachowanie jak i dane.]

https://java-design-patterns.com/patterns/domain-model/

Tak więc forsuję tezę, że diagram klas to albo model pojęciowy (związki taksonomiczne i predykaty między nazwami stosowanymi w danej dziedzinie) albo model dziedziny czyli mechanizm opisujący dane biznesowe i metody ich przetwarzania. W tym drugim przypadku jest to Model z wzorca MVC, a Model ten można stworzyć stosując np. wzorce DDD.

Model nie powinien być anemiczny:

Jednym z najczęstszych powodów powstawania anemicznych modeli domenowych jest sposób projektowania aplikacji w oparciu o wcześniej stworzony schemat bazy danych. To prowadzi to do tego, że model domenowy powstaje w skutek mapowania tabel do klas posiadających odzwierciedlone kolumny w postaci właściwości. Jedynym wyzwaniem dla niektórych osób może być modelowanie relacji, które w przypadku bazy danych są kluczami obcymi, zaś w przypadku obiektowego modelu powinny być relacjami do innych obiektów. Nie brakuje oczywiście przykładów, gdzie relacje w modelu domenowym tworzone są również w oparciu o klucze obce, co całkowicie zaprzecza obiektowemu programowaniu (źr. za pomocą Domain Model ? !FrAgile Thinking.)

Zwrócę tu uwagę na ważną rzecz: w modelach obiektowych systemów podstawowym związkiem (w j. ang. relation) jest związek użycia, jest to wywołanie operacji obiektu: w modelach obiektowych obiekty sie komunikują (wymieniają komunikaty), nie są to żadne trwale powiązane byty.

Polecam cały powyższy artykuł (no ja pomijałem część związaną z kodem bo już nie programuję ;). Polecam przy okazji artykuł: http://msdn.microsoft.com/en-us/magazine/dd419654.aspx.

Patrz także Anemiczny Model Dziedziny jako antywzorzec obiektowy.

Tagi: , ,

Jarosław Żeliński

Jarosław Żeliński: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.