98. O agregatach, eventach i Dynamic Consistency Boundary z Pawłem Pacaną
W świecie Domain-Driven Design, Agregat jest powszechnie uznawany za jeden z fundamentalnych wzorców odpowiedzialnych za spójność danych. To on wyznacza granicę transakcyjną, wewnątrz której pilnujemy niezmienników biznesowych, gwarantując integralność naszego modelu. Ale co w sytuacji, gdy ta z góry zdefiniowana, statyczna granica staje się pewnym ograniczeniem? Czy w każdym procesie biznesowym potrzebujemy dokładnie tego samego, silnego poziomu spójności i czy sztywny podział na agregaty zawsze idealnie odzwierciedla dynamiczną naturę problemu, który modelujemy?Okazuje się, że możemy podejść do tego zagadnienia w bardziej elastyczny sposób. W tym odcinku, wraz z moim gościem, Pawłem Pacaną z firmy Arkency, dokładnie przyjrzymy się koncepcji Dynamic Consistency Boundary. Porozmawiamy o tym, jak można myśleć o spójności nie jako o statycznej, raz ustalonej granicy, ale jako o koncepcji, która dopasowuje się do kontekstu konkretnej operacji biznesowej.W tym odcinku usłyszysz między innymi o:trudnościach w projektowaniu i długoterminowym utrzymaniu agregatów w systemieDynamic Consistency Boundary i czym ten wzorzec różni się od klasycznego podejścia z agregatemtagowaniu i linkowaniu zdarzeń pomiędzy strumieniamiwymaganiach dla event-store, aby stosowanie Dynamic Consistency Boundary było w ogóle możliwe pułapkach, na które należy zwrócić szczególną uwagę, by wykorzystanie DCB nie stało się problemMateriały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.
A gdyby ktoś chciał tak rozważyć właśnie użycie takiego konceptu jak dynamic consistency boundary w swoim projekcie, jakiej wiedzy by tak naprawdę potrzebował? Być może fajnie by to współpracowało z Awesome Decider, no bo de facto mam wszystkie dane odczytane, muszę teraz tylko podjąć na podstawie tego decyzję i ją zapisać. Ale czy użycie tego konceptu wymagałoby ode mnie posiadania jakichś specyficznych umiejętności, jakiejś specyficznej wiedzy? Na pewno. Tego konceptu użyjemy tylko w systemie opartym o zdarzenia. Operujemy tutaj na eventach. Musimy mieć jakąś intuicję pewnie do pracy z takimi eventami. Jeżeli pracowaliśmy z event-sourcowanym agregatem, to dla mnie tej przepaści tutaj nie ma. To jest trochę inny punkt widzenia na to, jak pracujemy z tymi strumieniami zdarzeń.
Poruszyłeś ciekawą rzecz z deciderem, bo to jest tak, że pozbywamy się tego agregata, ale problem nie znika. Ciągle musimy mieć coś, czym wypełnimy. To mięsko w środku gdzieś musi być jakoś zagospodarowane. To jest też ciekawe w DCB, że trochę może nam się zmienia optyka, bo patrzymy już na taki wycinek, na jedną klatkę. Ta klatka nazywa się obsługa jakiejś jednej operacji, jakiejś jednej komendy. I co my musimy spełnić w ramach tej jednej komendy, żeby podjąć decyzję? Ta decyzja jest oparta na zbiór zdarzeń, więc wybieramy sobie, ładujemy te zdarzenia, które nam mają pomóc podjąć tę decyzję, spełnić reguły. No i właśnie to jest to w środku, niezdefiniowane. Czym jest to w środku? Wydaje się, że decider tutaj pasuje fajnie.
Ja lubię decidera, bo to dla mnie daje takie fajne klocki, takie budulce, z których możemy budować inne komponenty. Wyobrażam sobie taki agregat czy aggregator zbudowany z elementów decidera i fajnie możemy te elementy ponazywać. Wskazać w sensie jak one się nazywają, tu bierze udział taki komponent, tu taki, tu taki. I ta używalność czy plastyczność decidera jest fajna. Mamy obsługę takiej komendy. Załadowaliśmy sobie te zdarzenia. Na końcu je gdzieś tam przypieczętujemy tą decyzję dopisując to w rezultat z tej operacji jako zdarzenie do tego ad hoc strumienia opartego o to query. ale w środku coś jest. W środku możemy sobie wsadzić ten decider.
Decider jako funkcja, która przyjmuje komendę i stan systemu, przy którym to wszystko zachodzi. Jeżeli decider sprowadzimy do dwóch rzeczy, do funkcji decide i do funkcji evolve, to zadaniem funkcji evolve jest zbudowanie nam jakiegoś stanu z listy zdarzeń. Natomiast zadaniem decida jest otrzymać taki stan i na podstawie tego stanu i komendy dostajemy naszym rezultatem jest jakieś zdarzenie, które opisuje zmianę. To jedyne, co tu się pojawia, to znaczy, że muszę jeszcze zrobić taką projekcję na podstawie tych zdarzeń, które wyciągnąłem z tej dynamicznej granicy i tak naprawdę to jest ten mój stan, który wrzucam do decidera. No, brzmi jak 2 plus 2 równa się 5. Myślę, że warto spojrzeć w kierunku decidera.
Pokazano wszystkie 4 dopasowania. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Kliknij, aby znaleźć fragmenty, w których pada.
W świecie Domain-Driven Design, Agregat jest powszechnie uznawany za jeden z fundamentalnych wzorców odpowiedzialnych za spójność danych. To on wyznacza granicę transakcyjną, wewnątrz której pilnujemy niezmienników biznesowych, gwarantując integralność naszego modelu. Ale co w sytuacji, gdy ta z góry zdefiniowana, statyczna granica staje się pewnym ograniczeniem?
Czy w każdym procesie biznesowym potrzebujemy dokładnie tego samego, silnego poziomu spójności i czy sztywny podział na agregaty zawsze idealnie odzwierciedla dynamiczną naturę problemu, który modelujemy?
Okazuje się, że możemy podejść do tego zagadnienia w bardziej elastyczny sposób. W tym odcinku, wraz z moim gościem, Pawłem Pacaną z firmy Arkency, dokładnie przyjrzymy się koncepcji Dynamic Consistency Boundary. Porozmawiamy o tym, jak można myśleć o spójności nie jako o statycznej, raz ustalonej granicy, ale jako o koncepcji, która dopasowuje się do kontekstu konkretnej operacji biznesowej.
W tym odcinku usłyszysz między innymi o:
trudnościach w projektowaniu i długoterminowym utrzymaniu agregatów w systemieDynamic Consistency Boundary i czym ten wzorzec różni się od klasycznego podejścia z agregatemtagowaniu i linkowaniu zdarzeń pomiędzy strumieniamiwymaganiach dla event-store, aby stosowanie Dynamic Consistency Boundary było w ogóle możliwe pułapkach, na które należy zwrócić szczególną uwagę, by wykorzystanie DCB nie stało się problemMateriały dodatkowe do tego odcinka znajdują się na stronie tego odcinka na bettersoftwaredesign.pl.
YouTube Alert! Odcinki podcastu są także dostępne na moim kanale na YouTube. Warto zasubskrybować, aby być na bieżąco z kolejnymi odcinkami.