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.

Better Software Design to podcast o projektowaniu oprogramowania. Wraz z moimi gośćmi rozmawiamy o architekturze, szczegółach implementacyjnych i wyzwaniach z tym związanych. Jeśli interesujesz się tworzeniem oprogramowania, to ten podcast jest właśnie dla Ciebie. Zapraszam na odcinek. Jak tak dalej pójdzie, to niezłego całą ekipę Arkansasi tutaj będę miał okazję gościć. Czemu nie? Cześć Paweł, witaj. Cześć. Wiesz, na początku zazwyczaj takie pytanie rozgrzewkowe jest, jak się zaczęła twoja historia z komputerem, ale dzisiaj chciałbym zrobić małego twista, bo chciałbym się zapytać, jak zaczęła się twoja przygoda z Rubim, bo ona trwa już, o matko, przynajmniej 15 lat, tak mi się wydaje.

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.

Mogę to sobie zrobić na zwykłej bazie relacyjnej i za pomocą Optimist In Clock'a całkowicie ten problem rozwiązać. Ale ten problem, o którym wspomniałeś, czyli być może ten design tego agregatu był właściwy kiedyś, ale się pozmieniało. i muszę teraz się dopasować, no to niestety muszę troszeczkę tą bazę danych pozmieniać, muszę coś tam do tego agregatu dorzucić, czasami coś wyjąć, czasami te rzeczy puchną, no i tak over the time mam na końcu troszeczkę problem z designem. To jest dosyć częsta przypadłość wielu systemów, które są gdzieś tam dewelopowane nie na przestrzeni powiedzmy dni, czy tam właściwie lat. Być może istnieją ludzie, którzy potrafią tak na strzała dobrze zaprojektować rzeczy. Może istnieją też systemy, w których się wymagania nie zmieniają. Może istnieją systemy, w których absolutnie nie zmieniają się wymagania i możemy zamrozić cały świat. Natomiast myślę, że tak realnie nasze rozumienie problemu też się może zmieniać, poza tym, że dochodzą nam nowe wymagania, a te, które były, mogą się też zmieniać.

Mniej zdarzeń potrzebujemy, bo zmieniła się reguła, której musimy pilnować. Wciąż te zdarzenia są w ramach jakiegoś taga, należą do jakiegoś konkretnego strumienia ad hoc, bo ten identyfikator trochę je tam kieruje. Tak, zapomniałem, że rozmawiałem z fachowcem od refaktoryzacji, z racji tego, że agencji to po prostu refaktoryzacja w DNA. Wydaje mi się, że refaktoryzacja... Chociaż powinniśmy ją wszyscy mieć, wiesz, jako branżę. Właśnie, właśnie. Z punktu widzenia refaktoryzacji wydaje mi się, że to jest w porządku. Natomiast do mnie ten argument do refaktoryzacji, która jest łatwiejsza, z DCB nie trafiał, bo my już w Age Event Store mieliśmy taki design, że można było linkować zdarzenia do różnych strumieni i tak naprawdę zmiana granic tego agregatu, jak on się mógł zmieniać w czasie, to było trochę przelinkowanie zdarzeń do innego strumienia i później zmiana kodziku, który sobie te zdarzenia czytał i operował na tym nowym strumieniu.

Więc w szczegółach implementacji to nie musi być takie łatwe. Zastrzegłem, z perspektywy użytkownika takiej biblioteki to brzmi całkiem sezownie. Paweł, korzyści z takiego podejścia są całkiem interesujące, bo nie muszę za bardzo wchodzić w projektowanie takiego, powiedzmy, statycznego designu mojego obiektu, gdyby się coś pozmieniało, to ja po prostu coś dodam, coś usunę, generalnie po jakiś inny strumień tych informacji sięgnę. Więc brzmi to troszeczkę jak taki święty graal szybkich modyfikacji aplikacji. Ale podejrzewam, że tam są jakieś takie szminy pod wodą, na które muszę zwrócić uwagę. Kilka z nich widzę, ale jestem strasznie ciekawy, jakie ty dostrzegasz w takim podejściu potencjalne problemy, z którymi ktoś mógłby się zderzyć. To jeszcze zanim do problemów, to wydaje mi się, że jakaś korzyść wynika też z tego, że być może nie musimy nazywać tego agregatu.

Te ograniczone, może tak, może grupa nie była mała, natomiast mało było miejsc dla tych kibiców w sektorze gości i bardzo chcieli kupić te miejsca i ten agregat sobie po prostu nie poradził, bo ten contention był tam, to zagęszczenie tych operacji współbieżnych było za duże i to był po prostu zły design. Wtedy się nauczyłem robić lepsze agregaty oparte o event sourcing, bo o krótszych strumieniach i trochę lepiej wyznaczyliśmy za drugim razem tą granicę spójności. To jest lekcja, którą też odrobiłem. Jakieś mi się wydawało, że snapshoty to jest rozwiązanie problemu. Nie, to jest maskowanie prawdziwego problemu. Po prostu twój design jest nie do końca optymalny i prawdopodobnie da się zrobić lepiej. Skracając strumień, dokładnie tak jak powiedziałeś. Drugim problemem, który ja dostrzegam, jest taki, że jeżeli mam możliwość wyciągnięcia dowolnych zdarzeń z dowolnych strumieni, to de facto mogę sięgnąć w dowolną część aplikacji.