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

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.

Jestem jednym z liderów projektu Realize Event Store, więc implementując Realize Event Store też mnie takie tematy interesują, czego ludzie używają albo jakie koncepty tam się pojawiają. I przyglądałem się trochę temu tematowi. Też w ramach takich spotkań firmowych, takiego book clubu, bierzemy sobie różne tematy i je rozkładamy na czynniki. Czyli to DCB pojawiło się właśnie jako jeden z tematów, które sobie analizowaliśmy, przegadaliśmy, skonfrontowaliśmy. Geneza tego tematu pochodzi od Sary Perlgini, jeżeli dobrze teraz wszystko pamiętam. Zgadza się. Ona miała taką prezentację Kill the Aggregates, w którym troszeczkę kwestionowała koncept agregatów i proponowała zupełnie inne podejście, które powiedziałbym będzie działać w świecie właśnie event store'ów, w świecie opartym o eventy i chyba nie znajdzie zastosowania tam, gdzie tych eventów nie ma, bo cała ta geneza opiera się właśnie o przeszukiwanie odpowiedniego streamu zdarzeń.

Ostatnia niezmienniki w granicach spójności. Odwołuj się do innych agregatów tylko i wyłącznie poprzez ich tożsamość. I inne agregaty zmieniaj tak naprawdę asynchronicznie. W sumie cztery proste zasady. Można powiedzieć, where is the problem? Tak, wydaje mi się, że to, do czego uderzała Sara, to to, że ta definicja agregatu może nie być klarowna, dla kogoś to dopiero zaczyna i że tą intuicję dopiero nabywa się z jakimś doświadczeniem, a jak już wdepniemy w jakiś design, to być może trudno jest już później z niego wyjść i trochę go przemodelować. Mam wrażenie, że to trudność z wyjścia z jednego designu w drugi może być trochę spowodowana jakimś wpływem tego, jak zaprojektowany jest sam EventStore, który nas w tym zadaniu wspiera, bądź nie. 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.

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?

Wydaje mi się, że samo to zaciąganie zdarzeń z dosłownie każdego zakątka systemu jest trochę bardziej ograniczony, bo wciąż operujemy w ramach jakichś tam tagów, czy tych identyfikatorów domenowych, jak je nazywa Sara. A one są już ściśle w ramach jakiegoś baudet kontekstu, więc wydaje mi się, że jednak poruszamy się w jakimś ograniczonym obszarze. Natomiast zgodzę się co do tego, że trochę spekulujemy, jak dobre będzie to DCB, albo jakie problemy natrafimy, a dowiemy się dopiero za jakiś czas. Skala na pewno jest szeroka. Ale tak, to byłoby rozwiązanie. Ograniczmy się tylko i wyłącznie do zdarzeń z danego kontekstu i wtedy powinno być tacy. Jeżeli tutaj nasze konteksty zostały dobrze wyznaczone, brzmi jak całkiem sensowne rozwiązanie.

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,