czwartek, 13 października 2016

DDD w praktyce #0 - Model domeny

Od pewnego czasu chodził mi głowie pomysł by napisać coś o DDD. Tak się złożyło, ze u mnie w firmie powstaje element systemu o nazwie Audit, który będzie służył do zarządzania (planowanie, wykonanie, raportowanie) audytami.

Zdecydowałem się pokazać na blogu jak napisać taki system w oparciu o reguły DDD (głównie ze względu na to, że w obecnym projekcie nie korzystamy z DDD). Aby urealnić cały proces, wymagania które będziemy implementować będą pochodzić z rzeczywistej domeny. Oczywiście będzie to tylko mały podzbiór rzeczywistych wymagań, ale powinno to być wystarczające by pokazać jak takie projektowanie może przebiegać. Zastrzegam, że kod który tu pokazuję nie jest kodem produkcyjnym, ani też jego implementacja nie jest jedyną idealną.


Zanim zaczniemy pisać kod powinniśmy wiedzieć jak wyglądają procesy w domenie, której zachowania i reguły będziemy implementować. W tym celu ekspert domenowy (Domain Expert) przygotowuje tzw. model domeny (Domain Model). Model dziedziny ma za zadanie pokazać jak system ma działać.

Jednym z modeli od jakiego możemy zacząć modelowanie dziedziny jest tzw model pojęciowy. Pomoże nam on na samym początku poznać związki i pojęcia używane w domenie.

Popatrzmy na poniższy diagram.


Na tę chwilę model ten pokazuje tylko obiekty i relacje pomiędzy nimi. Nie mamy jeszcze zdefiniowanych atrybutów i zachowań dla obiektów. Jest on jednak wystarczający by poznać z grubsza reguły jakie obowiązują w domenie. Z diagramu wynika, że AuditProgram zarządza manages audytem (Audit) i posiada has zespół Team. Na tę chwilę taki prosty model pojęciowy jest wystarczający.

Mając model pojęciowy możemy pokusić się o przygotowanie modelu dziedziny, który przedstawi nam atrybuty, odpowiedzialności i ograniczenia obiektów domeny. Model taki powstaje poprzez identyfikację klas posiadających odpowiedzialności i atrybuty.




Na powyższym diagramie klasa AuditProgram ma metodę AddTeam która służy do przypisania zespołu do programu. Oprócz tego posiada ona takie atrybuty jak Number i Type. Do tworzenia obiektów AuditProgram korzystamy z fabryki (dlaczego tak wyjaśni się w jednym z następnych artykułów). Na diagramie widzimy również serwis domenowy AuditProgramNumberGenerator, który jak nazwa i jego zachowanie (metoda NextNumber()) wskazują służy do generowania numeru programu.

Związek pomiędzy AuditProgram a Audit jest przedstawiony jako kompozycja (czarny romb na jednym z końców relacji). Jest to najsilniejszy ze związków jakie mogą łączyć dwa obiekty. W prostych słowach mówi o tym, że jeden obiekt nie może istnieć bez drugiego. W naszej domenie AuditProgram zarządza manages audytami więc obiekt Audit nie może istnieć bez swojego nadzorcy (AuditProgram). Liczność nad linią związku mówi nam o tym, że AuditProgram może zarządzać jednym lub wieloma audytami (Audit). Model na tym etapie nie jest pełny, klasom brakuje atrybutów i odpowiedzialności, zostaną one dodane później w procesie tzw destylacji domeny.

Ważnym elementem każdego modelu dziedziny jest język wszechobecny (Ubiquitous Language). Służy on do komunikacji pomiędzy ludźmi biznesu, a zespołem realizującym projekt w tym zespołem IT. Wprowadza on jednoznaczność pojęciową do sposobu w jaki się komunikujemy, przez co unikamy nieporozumień związanych z dwuznacznością pojęć. Ważną częścią modelu domeny jest słownik pojęć, w którym definiujemy znaczenie wszystkich pojęć jakie występują w modelowanej domenie.

Ja w tym miejscu zakończę prezentację procesu modelowania dziedziny. Koledzy analitycy dodali by pewnie do tego modelu kolejne diagramy jak diagram sekwencji (opisujący operacje w klasach), diagram stanów i tak dalej. Ja w tym wprowadzającym artykule chciałem zaznajomić was z pojęciem modelu dziedziny. Po więcej odsyłam do ekspertów (linki na końcu artykułu).

W następnej odsłonie zajmiemy się obiektami domeny.

Aktualizacja [12-12-2016]
Z przykrością informuję, z przyczyn osobistych seria postów o DDD zostaje wstrzymana.

Głos ekspertów w temacie...
[1] Szymon Pobiga - Mentoring DDD. Powstawanie modelu
[2] Jarek Żeliński - DDD nie metoda a styl
[3] Sławek Sobótka - DDD Sposób na projektowanie złożonych modeli biznesowych
[4] Jarek Żeliński - Plansza do gry w szachy, czyli analiza i projektowanie

Brak komentarzy:

Prześlij komentarz