Moduły w Niebieskiej Książce Eric'a Evans'a

Large Scale Domain Concept

 

Eric sugeruje by rozpatrywać moduły jako bloki budulcowe taktycznego DDD takiej samej rangi jak Agregaty, Encje czy Value Object'y. Jest to koncept większej skali, grupujący inne mniejsze powiązane ze sobą koncepty domenowe. Od strony kodu źródłowego moduły będą reprezentowane przez konkretne namespace'y zawierający obiekty i interfejsy.

  

Moduł pochodzi z modelu domenowego, a jego nazwa z Ubiquitous Language - nie powinien więc on być tylko elementem kodu źródłowego służącego do zredukowania złożoności. Ułatwia to komunikację z ekspertami domenowymi ponieważ możemy szybko ustalić kontekst poruszanego problemu czy też posługiwać się bardziej ogólnym pojęciami rozumianymi przez każdą ze stron.

Moduł skupiający mniejsze domenowe pojęcia

Spoglądając na aplikację z lotu ptaka, wprowadzone moduły sprawiają, że zyskujemy nową perspektywę wglądu w tworzony system. Możemy spojrzeć na to w jaki sposób koncepty większej skali ze sobą współpracują, bez niepotrzebnego rozpraszania się złożonością (liczne klasy i interfejsy) którą heremtyzują. 

Możliwość spojrzenia na aplikację monolityczną z wysokości nie jest sprawą oczywistą i dostępną od tak. Najpierw należy wykonać pracę analizującą dokładną zawartość modułów oraz ustalić relację między nimi nazwiązane. Niewątpliwie jest to opłacalna inwestycja ponieważ daje nam możliwość lepszego zrozumienia domeny problemu. Na podstawie takiego przeglądu możemy dojść do wniosku, że niektóre z modułów mają zbyt dużo odpowiedzialności lub relacje między modułami są nielogiczne lub dwukierunkowe.    

Relacje z innymi Modułami 

Relacje między modułami

Dzieląc klasy i interfejsy na moduły wartoby było monitorować ich relacje z innymi modułami. Nie powinniśmy rozpatrywać zależności modułów między sobą jako coś złego, to normalne że komunikują się ze sobą nawzajem. Relację można traktować jako element modelu i wartość samą w sobie.

 

Uważnie śledząc kierunek relacji modułów możemy sprawdzić w jaki sposób moduły są od siebie zależne. Powinniśmy pilnować by liczba relacji w module lokalny do modułów zewnętrznych była jak najmniejsza i jednokierunkowa. Jeżeli tak nie jest to warto przeanalizować funkcjonalności w innych modułach od których moduł lokalny jest zależny. 

 

Jeżeli koncept domenowy z modułu zewnętrznego jest spójny z tymi znajdującymi się w module lokalnym wszystko wskazuje na to, że to w nim powinna być umiejscowiona funkcjonalność. 

Low Coupling & High Cohesion

 

Zasada jak najmniejszej ilości powiązań (Low Coupling) jest ściśle związana z zasadą wysokiej spójności (High Cohesion) konceptów/reguł/logiki. Jeżeli moduł ma wiele powiązań z innymi modułami (High Coupling) to znaczy, że funkcjonalności dotyczące jednej dziedziny problemu zostały rozbite na kilka modułów - stąd potrzeba wielu powiązań między nimi. 

 

Istotną korzyścią płynącą ze stosowania się do tych zasad jest fakt, że o wiele łatwiej pracować z wysoce spójnymi i luźno powiązanymi modułami. Programiści wprowadzający zmiany w takim obszarze będą mieli do czynienia z klasami reprezentującymi tylko konkretną część domeny. 

 

Liczba klas w module będzie więc ograniczona, dlatego nie powinniśmy być przeciążeni kognitywnie analizując je wszystkie razem w celu zrozumienia pełnego konceptu. Ewentualne powiązania do innych bytów będą nieliczne i jasno zdefiniowane.   

       

Warto zwrócić uwagę, że pilnowanie by implementowany byt był luźno powiązany i wysoce spójny powinniśmy stosować zarówno podczas pracy z modułami jak i obiektami - zasada jest uniwersalna.

Ciągły Refactor

 

Tak jak pozostałe building block'i taktycznego DDD wymagają przeprowadzania ciągłej refaktoryzacji - tak samo powinniśmy postępować z modułami. 

 

W przypadku modułów refaktoryzacji zazwyczaj powinno być poddawane umiejscowienie konceptów/reguł/logiki w nich zawartych. Jeżeli łamiemy zasadę wysokiej spójności powinniśmy przenieść funkcjonalność do innego modułu. 

 

Moduł A posiada niespójny koncept

 

Kiedy żaden z istniejących modułów nie wydaje się wystarczająco odpowiednim miejscem należy rozważyć utworzenie nowego modułu. Wskazówki co do jego potencjalnej nazwy może dać rozmowa przeprowadzona z przedstawicielem biznesu. Zazwyczaj jest to wcześniej nieodkryty bądź niejawny koncept domenowy.

Jak zauważa Evans, programiści nie są skorzy do przeprowadzania refaktoru modułów i zadowalają ich granice/nazwy ustalone na samym początku ich powstania, a jak często wspominał, pierwotny model jest zazwyczaj naiwny.

 

Można wyciągnąć wnioski, że są one kłopotliwe do refaktoru ponieważ:

• wymagają znacznie większego zakresu prac niż refaktor obiektów,
• wymagają spojrzenia na kod z innej perspektywy w celu dostrzeżenia ewentualnych miejsc do poprawy,  
• trudno wpaść na lepszy pomysł podziału na moduły
  bądź programiści w ogóle nie biorą pod uwagę tego, że ten aspekt projektu mógłby zostać ulepszony.

Warto więc rozpatrywać następujące aspekty modułów i zastanowić się nad ich poprawnością:

• granice, 
• nazewnictwo, 
• ukryte koncepty, 
• nieaktualne byty.

 

Powinniśmy liczyć się z tym, że prace refaktoryzacyjne w tych obszarach nie będą tak często przeprowadzane i same moduły pod względem ich aktualności "będą stały w tyle" za resztą konceptów.  

 

Opracowanie na podstawie

📚 Eric Evans "Domain Driven Design: Tackling Complexity in the Heart of Software" str. 109-115.