Domain Driven Design – Agregat

Z serii ostatnich artykułów znasz już praktyczne wszystkie elementy modelu. Jeśli przegapiłeś, znajdziesz je TUTAJ. Dzisiaj mam dla Ciebie coś pomiędzy ostatnim elementem modelu a już strategią układania tych klocków w model. To coś to Agregat root, skąd właśnie na zdjęciu są korzenie. W tym poście poznasz szczegóły czym jest i jak go używać w swoim modelu. Zaczynamy!

Czym jest agregat?

Agregaty to taktyczny wzorzec DDD, który bardzo wzmacnia model domeny. Określa jasne zasady własności modelu oraz jego granice, co rozjaśnia obraz modelu i zapobiega zbytniemu skomplikowaniu. Dzięki jego poprawnym użyciu obiekty zachowują swoją integralność. Agregaty grupują encje oraz wartości i tworzą na nich warstwę abstrakcji, która będzie zarządzać dostępem do danych.

Każdy agregat powinien posiadać swój korzeń i granice. Korzeniem jest główna, najważniejsza encja, która wchodzi w relację z innymi encjami wewnątrz agregatu. Wszystkie encje oprócz korzenia posiadają swoją tożsamość, ale będzie ona nazywana tożsamością lokalną. Tożsamość lokalna, różni się od zwykłej tożsamości tym, że encje będą rozróżniane jedynie wewnątrz agregatu. Obiekty z zewnątrz nie będą miały do niej dostępu.

Trudności

W kontekście agregatów jako spójnych struktur danych związanych ze sobą asocjacjami trzeba pamiętać o warstwie zapisu. Skoro agregat jest hermetyczną całością, to odczytanie go powinno być jednym procesem, który zwraca nam komplet danych. Podobnie jest z zapisem. Utrwalenie agregatu jest równoznaczne z utrwaleniem korzenia i wszystkich zależnych encji w jednym procesie. Naturalnym rozwiązaniem zabezpieczenia takiego procesu jest transakcja. Doskonale sprawdza się w tej sytuacji, jednak programista musi bardzo uważać w trakcje budowania agregatu na zależności między wewnętrzami encjami i wartościami, aby nie stworzyć zamkniętych obiegów relacji.

Dodatkową trudnością przy bardziej skomplikowanych agregatach jest dopuszczalność zmiany stanu między encjami wewnątrz agregatu. Należy bardzo uważać, aby jednoczesna praca na tym samym agregacie nie powodowała zmian stanów, o których korzeń nie ma świadomości. Niepotrzebne referencje do obiektów, szczególnie udostępniane przez korzeń mogą powodować duże problemy. Co do wartości, zgodnie z ich definicją, czyli pobranie wartości równa się otrzymaniu kopii obiektu.

Agregat powinien zawierać jasne definicje niezmienników. To reguły biznesowe, które w ramach agregatu muszą byś spójne. Podczas utrwalania agregatu wszystkie niezmienniki musza być spełnione np. posiadając agregat, którego niezmiennikiem jest reguła c = a – b, to podczas zatwierdzania agregatu jest ona sprawdzana. W przypadku, gdy nie zostaje spełniona, agregat powinien zwrócił błąd o braku spójności, ponieważ niezmiennik został naruszony.

Spójność

Wyróżniamy dwa typy spójności. Spójność transakcyjną oraz ostateczną. Spójność transakcyjna oznacza, że dane między transakcjami, czyli procesami przeprowadzającymi kolejki modyfikacji powinny zachowywać spójność. Jednak nie jest ona weryfikowana w trakcie trwania transakcji. W przypadku niezmienników programista powinien się skupić na spójności transakcyjnej. Spójność ostateczna oznacza, że ostatecznie dane będą spójne bez określania po jakim czasie to nastąpi. Jednak w niektórych sytuacjach to właśnie ona powinna być weryfikowana.

Programiści używający tradycyjnego podejścia do DDD, będą optować za spójnością transakcyjną. To dla tych, którzy w swoich modelach domenowych projektują rozwiązania CQRS, ważniejsza będzie spójność ostateczna. Jest to jednak ściśle związane z technicznymi preferencjami architektów. Autorzy podejścia DDD podpowiadają aby przed zdecydowaniem się, na którą spójność w danej aplikacji powinien być położony większy nacisk, architekt powinien zadać sobie pytanie, na kim będzie spoczywała odpowiedzialność za doprowadzenie do tej spójności. Jeśli będzie to zadanie użytkownika, zalecane jest stosowanie spójności transakcyjnej. Jeśli jednak to zadanie systemu lub innego użytkownika, niż ten, który uruchamia proces, nacisk powinien być położony na spójność ostateczną. Dzięki takiemu podziałowi łatwiej będzie wyróżnić reguły, które staną się niezmiennikami.

Podczas projektowania agregatów bardzo przydane są dwa wzorce projektowe. Mowa tutaj o Prawie Demeter inaczej nazywane Powiedz, nie pytaj.

Jeśli masz pytania, coś jest dla Ciebie niezrozumiałe, 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