Mentionsy
Better Software Design
Better Software Design
09.09.2025 23:00

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ę problem

Materiał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.

DCB Paweł Rubiego store'a EventStore'a Axon Ruby'ego Sara Rubim Be Axona Decider Dolnośląskiej Grupy Użytkowników Rubiego Dynamic Consistency Boundary DECB

Szukaj w treści odcinka

Wyczyść
Znaleziono 5 wyników dla "store'a"

Tak nawiązałeś do EventStore'a, ale jeżeli będę chciał mieć system, w którym będę wykorzystywał ten wzorzec agregatu, ja wcale nie muszę korzystać z bazy eventowej.

Z punktu widzenia event store'a chcielibyśmy raczej, żeby ten payload danych, które mamy w zdarzeniach, był dla nas taki nieprzejrzysty.

To jest bardzo dobre pytanie, bo wspomniałeś o jednym, czyli to, że być może będziemy mieli problem przy samym zapisie do EventStore'a, bo musimy zrobić to zapytanie, którego w podejściu z nazwanym strumieniem i pilnowaniem jakiegoś constrainta, jeżeli to byłaby implementacja oparta relacyjna bazy danych, byśmy nie mieli.

Tylko zobacz, że tutaj też ciężar znika nam i problem w jednym miejscu aplikacji, a pojawia się w drugim, bo ja wiem, że dla ciebie to jest bardzo naturalne, bo ty jako kontrybutor jest event store'a, to tak naprawdę chyba pracujesz z tym na co dzień, ale ktoś, kto nie ma doświadczenia w projektowaniu aplikacji opartych właśnie od streamy zdarzeń, to tu jest miejsce, gdzie ktoś się może po prostu potknąć i przewrócić.

Bo to, co tutaj Paweł wspomniałeś, to oznacza, no dobra, no to w sumie tylko przy zapisie muszę odesłać jeszcze raz tą kwerendę i podać identyfikator strumienia, czyli metoda save mojego event store'a po prostu musi być jakoś rozszerzona.

Ostatnie odcinki