Domain Driven Design – Fabryka

Z tygodnia na tydzień coraz więcej uwagi przeznaczam na DDD i pokazanie Ci jak szerokie jest to pojęcie. Elementy modelu już omówiłam w poprzednich postach, teraz czas na wzorce, które pojawiają się w DDD i za co są one odpowiedzialne. Pierwsza na tapet idzie Fabryka. Zaczynamy!

Cykl życia każdego obiektu rozpoczyna się od jego zainicjalizowania. W tym procesie powinny zostać również nadane wartości wszystkim wymaganym parametrom, aby zachować spójność obiektu. Takie podejście zapewni również bezpieczeństwo procesów, ponieważ zawsze otrzymując dany obiekt wiemy, że będzie on kompletny. Tworzenie i uzupełnianie danych obiektu czy składanie agregatów to procesy, które bardzo często są skomplikowane i mają jedno, konkretne i znaczące zadanie do wykonania – dostarczenie kompletnego obiektu.

Programiści często bagatelizują tą odpowiedzialność, nadając ją serwisom czy klientom. Prowadzi to bardzo często do dehermetyzacji i rozpłynięcia się wiedzy po częściach systemu, które nie powinny takiej wiedzy posiadać. Poprawnym podejściem jest stworzenie struktury, której odpowiedzialnością będzie jedynie zbudowanie kompletnego obiektu z dostarczonych jej danych. Ta struktura to właśnie fabryka.

Fabryka – co to takiego?

Fabryki są klasami, które mają jedną bardzo ważną odpowiedzialność w całym systemie, czyli tworzenie kompletnych obiektów encji, wartości lub agregatów. Tylko one powinny się tym zajmować. Na wejściu powinny dostawać dane do zbudowania obiektów wyjściowych. Jeśli te dane nie są wystarczają, to powinny rzucać błąd. Oczywiście w kontekście parametrów wymaganych. Parametry opcjonalne mogą być w nich ustawiane, ale nie powodują błędów. Fabryki nie powinny dociągać danych z innych źródeł. Jednak mogą wywoływać inne fabryki budujące obiekty wchodzące w relacje np. podczas budowania agregatu.

Ogólnie znane wzorce projektowe tj. Factory Method, Abstract Factory czy Builder mają swoje zastosowanie w fabrykach definiowanych przez DDD. Ich znaczenie zostaje dodatkowo podkreślone w projekcie starowanym modelem, ponieważ ich poprawne zastosowanie uprości utrzymanie projektu. Przykład wzorca Factory Method prezentuje rysunek Rysunek 2.

Źródło: [Sanders W. PHP. Wzorce projektowe, Helion, Gliwice 2013 s. 82].

Fabryka i agregat

W przypadku agregatu fabryki i metody wytwórcze są bardziej skomplikowane i wymagają dłuższego zastanowienia, ponieważ zła implementacja może powodować zachwianie reguł ograniczonego dostępu i nieświadomie udostępnić więcej niż tylko referencje obiektom spoza agregatu. Jedną z opcji jest stworzenie dedykowanej samodzielnej fabryki, która zostanie jedynie użyta przez odpowiednią metodę agregatu. Druga to zaimplementowanie metody wytwórczej w agregacie, co jest bezpieczniejsze z perspektywy spójności, jednak mniej użyteczne przy bardziej skomplikowanych obiektach wewnętrznych agregatu.

Niezależnie od wybranej metody fabryka jest nierozerwanie związana ze swoim produktem, stąd też powinna być udostępniania jedynie obiektom ściśle z nim związanym. Jak już zostało wspomniane w poście o agregatach, muszą one spełniać wewnętrzne niezmienniki. W przypadku, gdy jedna fabryka tworzy cały agregat warto się zastanowić, w którym miejscu powinny być one weryfikowane. Czy powinno to być odpowiedzialnością samego agregatu, czy może przeniesione do fabryki? Oba podejścia są poprawne.

Na dzisiaj to by było na tyle. Masz dodatkowe pytania? Napisz w komentarzu albo w wiadomości prywatnej na FB.

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