Mentionsy
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.
Szukaj w treści odcinka
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ć.
Poruszyłeś ciekawą rzecz z deciderem, bo to jest tak, że pozbywamy się tego agregata, ale problem nie znika.
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ć.
I ta używalność czy plastyczność decidera jest fajna.
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ń.
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.
Myślę, że warto spojrzeć w kierunku decidera.
Ostatnie odcinki
-
99. O architekturze oprogramowania w erze AI-As...
05.02.2026 00:00
-
98. O agregatach, eventach i Dynamic Consistenc...
09.09.2025 23:00
-
97. O architekturze mikrofrontendów i mikroserw...
07.04.2025 23:00
-
96. O dostarczaniu eventów w systemach rozprosz...
25.03.2025 00:00
-
95. O architekturze mikrofrontendów i mikroserw...
05.03.2025 00:00
-
94. O integracji serwisów z użyciem kontraktów ...
04.02.2025 00:00
-
93. Backend vs Frontend: skuteczne testowanie z...
15.01.2025 00:00
-
92. O wykorzystaniu AI w software developmencie...
23.12.2024 00:00
-
91. O modułach w aplikacjach JavaScript z Tomas...
11.12.2024 00:00
-
90. O projektowaniu architektury multi-tenant z...
19.11.2024 00:00