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.
To było wielkie wydarzenie. Natomiast Ruby w tym czasie to był 1.8 jeszcze. I pamiętam, że miałem jakieś opory do uczenia się tego Ruby'ego, bo Python'y już znałem dobrze. To w zasadzie było bardzo bliskie i podobne, ale tak się polubiliśmy, że zostałem z tym Rubiem do dzisiaj. No i przy okazji tam trochę kontrybuujesz, bo pewnie o tej kontrybucji do pewnych znanych bibliotek to też gdzieś tutaj będziemy rozmawiać. Zresztą chyba to jest taka geneza wielu osób w Arkensji, gdzieś zeswitchowali się w międzyczasie do Rubiego. Bo tak Andrzej mi się kojarzy zawsze jako dżawowiec. Przynajmniej ja go poznałem w dawnych latach jeszcze w Instytucie Informatyki Uniwersytetu Wrocławskiego, jak przyszedł na zajęcia chyba z wytwarzania oprogramowania i wówczas był zatwardzajem dżawowcem, a dzisiaj... Chyba nie zostało po tym śladu. Mamy takie różne smaki właśnie w Arkansas. Są jobowcy, są dotnetowcy. Natomiast w tej historii zrobił mi się jeszcze coś takiego, że to mniej więcej wtedy, kiedy ja się przekonwertowałem na Rubiego, też zainicjowałem takie spotkania Dolnośląskiej Grupy Użytkowników Rubiego, w skrócie DRUG.
Google Was nie lubi pewnie za tą nazwę. Nie pozycjonuje się. Myślę, że możemy być trochę penalizowani. Natomiast drugi jest ciekawym speed-upem, bo my tam paradoksalnie bardzo mało mówimy o Rubim, bardzo różnych tematów tam się przewija. Te spotkania w pewnym momencie były tak popularne, że postanowiliśmy je sforkować do konferencji. Powstała konferencja Wrocław RB, która też miała taki żart o tej konferencji, że to jest najbardziej czowowa konferencja Rubiego. Ale to jest konferencja z klimatem, bo za każdym razem, kiedy tam jestem, tak czuję się, że to jest zupełnie inny event. Jeżeli ktoś chciałby zobaczyć, na czym ta zabawa polega, to serdecznie zapraszamy. To wydaje mi się, że to jest jakoś tak pod koniec, przełom wiosny-lata zazwyczaj, jakiś taki termin we Wrocławiu? Konferencja jest w kwietniu. Myślę, że to będzie druga połowa kwietnia przyszłego roku. Natomiast spotkania drugowe mamy w każdy trzeci poniedziałek miesiąca o 19.
jest zaimplementowany w TypeScriptie na stronie dcb-events. My ten przykład i ten kodik z TypeScripta przenieśliśmy na Rubiego i na Edge Event Store i można sobie zobaczyć, jak te przykłady w Edge Event Store wyglądają, ze wsparciem w dwóch trzecich i z tą nakładką na append, która na potrzeby przykładów działa. W produkcyjnym systemie musimy to zaimplementować po prostu. W swoim arsenale masz tak naprawdę dwa narzędzia. Masz wzorzec Aggregate, który oferuje ci tą statyczną granicę. Jest dosyć jednak rozpowszechnionym wzorcem i ma tam troszeczkę powiedzmy plusów i minusów. Obok jest drugie narzędzie Dynamic Consistency Boundary. W jakich przypadkach zdecydowałbyś się na jedno i drugie rozwiązanie? Kiedy byś użył agregatu? A kiedy byś użył takiego klasycznego, nawet prezystowanego do bazy danych, gdzie ta struktura tego agregatu jest już ściśle zdefiniowana?
Czy jakiś styl lepiej uwypukla rozwiązania, czy gorzej. Takie porównanie side by side dwóch rzeczy można sobie z tego repo zrobić. Implementacji jest tam już chyba kilkanaście. I podobną koncepcję mamy do repozytorium dynamic consistency boundary, gdzie mamy jeden przykład i tą implementację na razie typescriptową przeniesioną 1 do 1 do Ruby'ego, ale pojawi się tam też implementacja bardziej idiomatyczna Ruby'owa. Jeżeli ktoś chce się przekonwertować na Ruby'ego, to myślę, że to będzie raczej ta implementacja. Ale też chcemy tam pokazać dla kontrastu różne implementacje oparte o agregaty. Trochę też takie na brzegach spektrum, żeby może bardziej uwypuklić jakieś problemy i zastanowić się, czy coś na tych brzegach spektrum DCB robi lepiej.
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.