Domain Driven Design – Moduły

Moduły zwane również pakietami to elementy modelu grupujące inne mniejsze elementy. Są one dobrze znane architektom i programistom jako pakiety w języku JAVA czy przestrzenie nazw w PHP lub C#. Umożliwiają one dwa spojrzenia na architekturę systemu. Pierwsze to spojrzenie szczegółowe, czyli zagłębienie się w logikę danego modułu bez konieczności poznawania reszty systemu. Drugie to analiza komunikacji i relacji między modułami. Możliwość spojrzenia na system w bardziej całościowy sposób. Domain Driven Design również wyróżnia moduły jako element modelu zaraz po encjach, obiektach wartości i usługami. Dlatego dzisiaj powiem co nieco więcej na ich temat.

Czym są moduły?

Podział systemu na moduły jest naturalnym podejściem do architektury. Zarówno doświadczeni programiści, jak i ci zaczynający stosują moduły, jednak nie każdy uznaje je za pełnoprawny element modelu. Moduły powinny być ze słabo ze sobą związane i jednocześnie spójne. W kontekście DDD musimy jednak pamiętać, że nie mówimy tutaj o fizycznym i technicznym podziale kodu a pojęć dziedziny.

Odpowiednio zaprojektowane moduły minimalizują koszty i dokładniej prezentują logikę biznesową poprzez wyróżnienie, które pojęcia dziedziny są ze sobą silniej, a które mocniej związane. Wysoka spójność i słabe związanie są szczególnie ważne i mają duże znaczenie na wyższym poziomie projektowania i modelowania systemu. Między elementami modelu powinna zachodzić synergia, czyli pakiety powinny skupiać w sobie pojęcia o szczególnie bliskich sobie związkach i powiązanych odpowiedzialnościach.

Moduły nadają pewien kontekst w rozmowach między członkami zespołu, szczególnie z ekspertem dziedzinowym. Eric Evans porównuje moduły do rozdziałów książki, którą jest projekt. Nazwy modułów powinny być głównymi pojęciami stosowanymi w języku wszechobecnym i odzwierciedlają wiedza dziedzinową.

Bardzo częstym problemem związanym z modułami jest ich zwinność. W trakcie rozwoju poszczególnych klas i obiektów zawartych w module albo programista na siłę próbuje wcisnąć logikę zmian w ramy modułu, albo wręcz przeciwnie, rozbudowuje je, nie myśląc o założeniach podziału. W takich sytuacjach powinna zostać wykonana refaktoryzacja pakietu. Niestety bardzo rzadko programiści decydują się na to, ponieważ jest to kosztowne, a nie przynosi zysku biznesowego. Nie zastanawiając się nad zakresem modułu bardzo często dochodzi do zmniejszenia spójności wewnątrz lub zbytniego związania z innym modułem.

Cykl życia obiektu

Każdy obiekt ma swój cykl życia tak jak zostało to przedstawione na rysunku Można powiedzieć, że rodzi się w momencie jego zainicjowania i co za tym idzie, alokacji pamięci. Zostaje poddany zmianom jego zawartości, czyli zmienia swój stan. Aby ostatecznie umrzeć przy jego świadomym usunięciu lub przy czyszczeniu pamięci.

Obiekty mogą mieć różną długość życia np. relacje z innymi obiektami mogą je wydłużyć. Zarządzanie obiektami może być dla programisty ciężkim zadaniem, szczególnie jeśli decyduje się na użycie projektu sterowanego modelem. Jednym z głównych problemów jest utrzymanie integralności obiektu w całym cyklu jego życia, zwrócenie szczególnej uwagi na jego hermetyzację.

Kolejną trudnością jest zbytnie skomplikowanie organizacji cyklu życia obiektów, co może doprowadzić do sytuacji, gdzie model stanie się nieczytelny. W zarządzaniu cyklem życia obiektów pomagają trzy wzorce, które omówione zostaną później w tym rozdziale. Będą to agregaty, fabryki i repozytoria.

Źródło: [Evans. E DDD zapanuj nad złożonym systemem informatycznym,
Helion, Gliwice 2015 s. 155].

Z wpisu na wpis, elementy modelu się bardziej skomplikowane i mniej oczywiste. Jednak mam nadzieję, że udaje mi się wytłumaczyć w zrozumiały sposób. Jeśli masz jakieś pytania, pisz śmiało w komentarzu.

Podobne posty

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.

Comments

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here