98. O agregatach, eventach i Dynamic Consistency Boundary z Pawłem Pacaną

Kwestie finansowe schodziły na drugi plan. Oczywiście przy zachowaniu kilku kluczowych reguł. Najprostszym rozwiązaniem byłoby być może skolejkowanie wszystkich nadchodzących zmian lub wręcz lokowanie całej bazy podczas wykonywania operacji, ale umówmy się, w niewielu systemach mamy taką właśnie możliwość. W projekcie tym finalnie zaimplementowaliśmy rozwiązanie nazwane przez nas agregatem o dynamicznym kształcie, który z dość specyficznym sposobem zrównoleglania operacji z zapisu potrafił faktycznie obsłużyć taki dziwny przypadek. Ale równie dobrym rozwiązaniem tego problemu byłby koncept Dynamic Consistency Boundary, o którym będę dziś rozmawiał z Pawłem Pacanu. Nazywam się Mariusz Gil i zapraszam Ciebie na kolejny odcinek podcastu Better Software Design.

To serdecznie zapraszamy. Linki będą standardowo w opisie dla zainteresowanych. Ale Paweł, bo nie będziemy rozmawiać o Rubim, chociaż pewnie gdzieś zahaczymy o te klimaty, to było takie pytanie rozgrzewkowe, żebyśmy weszli w temat, bo chciałem dzisiaj troszeczkę porozmawiać na taki temat, który jest chyba troszeczkę owiany taką kontrowersją, przynajmniej w jakichś takich kręgach, bo nawet chyba sama osoba, która ten temat zapoczątkowała, miała takie podejście, no dobra, tutaj poruszmy tego niedźwiedzia śpiącego, agregatowego, no właśnie, bo będziemy rozmawiać o spójności, ale bez agregatów. Dokładnie, bo będziemy rozmawiać o Dynamic Consistency Boundary. Skąd w ogóle zainteresowani tym tematem u ciebie? No właśnie, historia i tło tego zainteresowania też jest takie konferencyjne, bo temat Dynamic Consistency Boundary pojawiał się w jakichś rozmowach kuluarowych, na meetupach i na konferencjach.

A jeżeli dołożymy sobie do tego jeszcze mikroserwisy i się nagle okaże, że podział tego agregatu, czy tam złączenie dwóch agregatów w jeden, bo właśnie się coś pozmieniało, no to jest troszeczkę większa szkoła trudności. Tak i poza złożonością, która wynika z problemu, będziemy mieli też trochę tej przypadkowej do pomieszczenia w głowie. No to więc od razu skręciliśmy takie negatywne tutaj nurty tej rozmowy. No to się nie dziwię, że Sara Pelegil nie chciała zabijać te agregaty. To jest ciekawe, że żeby wyjaśnić dynamic consistency boundary, potrzebujemy takiego antagonistę i przypisać mu dużo negatywnych cech, żeby pokazać, jak dobre jest to może konkurencyjne rozwiązanie, albo jak mogłoby być dobre. Czy dynamic consistency boundary wnosi tak dużo, jest takim przełomem, jak sugerowałaby prezentacja Kill the Aggregate?

Czy na pewno chcielibyśmy zabijać wszystkie agregaty? A to myślę, że chyba musimy zrobić, wiesz, cztery kroki też do tyłu, bo pewnie wiele osób nie oglądało tej prezentacji, bo to jest jednak temat dość nowy, chociaż w ostatnich, powiedzmy, nie wiem, może kilku miesiącach, to zaczęło się przebijać do jakiegoś takiego, może jeszcze nie mainstreamu, ale chociażby, wiesz, Axon do tego nawiązuje, gdzieś tam EventStoreDB, gdzieś widziałem, że też myśli o właśnie wprowadzeniu Dynamicon z sesji Bandari do swojej bazy danych, przynajmniej gdzieś taki tweet mi gdzieś tam mignął. Co to w ogóle jest? Dynamic Consistency Boundary to ma być taka technika, która pozwala nam zapewniać spójność w systemach opartych o zdarzenia i w ramach tego zapewnienia spójności nie musimy polegać na sztywnej granicy tej spójności, tak jak mamy to w agregacie. Jeżeli projektujemy agregat, to wszystkie operacje w tym agregacie korzystają z tej jednej granicy, którą w tym agregacie wyznaczyliśmy.

Conditional append. Kiedy wsparcie tego? W event store? Myślę, że wkrótce, najchętniej w najbliższym wydaniu. Dwie trzecie, czyli dwa z tych trzech warunków, po prostu już spełniamy. Nie dlatego, że zrobiliśmy je dla DCB, po prostu tak kiedyś zaprojektowaliśmy event store i okazało się, że mamy bardzo dużo wspólnego z DCB. Natomiast ta najtrudniejsza część i ta, gdzie mamy potencjalnie do rozwiązania problemy wydajnościowe i zbadania, czy one rzeczywiście wystąpią, to jest ten conditional append. To jest ten brakujący klocek. Natomiast już dzisiaj, jeżeli chcemy poeksplorować same przykłady DCB na takim systemie, który nie jest produkcyjny i problemy ze współbieżnością tam nie będą występować, no to sam problem, który Sara Pelegirni używa do przedstawienia konceptu dynamic consistency boundary, czyli studenci i kursy,

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?

Przynajmniej tak patrząc z mojej perspektywy, dynamic consistency boundary może być dla mnie ciekawe, jeżeli dopiero wchodzę do jakiegoś projektu, on jest nowy, jeszcze nie ma tego wszystkiego, powiedzmy, strony biznesowej bardzo mocno okrzepniętego i to tak naprawdę ewoluuje. Więc wtedy po prostu będę zmieniał query i nie będę musiał dużych refaktoryzacji robić. Ale jeżeli biznes jest już okrzepnięty i wszystkie takie ścieżki zostały przedreptane i ja muszę rozwiązywać jakieś problemy wydajnościowe, to wtedy faktycznie mógłbym się odnieść po wzorze z AGG, bo dokładnie wiem, jakie tam są reguły, dokładnie wiem, jakie dane są potrzebne. I wtedy mógłbym się pokusić o ten rozwiązek. Więc przynajmniej tutaj taką dostrzegam możliwość wyboru. Czyli lepszy znany warunk niż... W jakimś stopniu. Chociaż oczywiście znowu zaprojektowanie agregatu takiego optymalnego, to też jest kurczę sztuka.

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ń.

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.