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

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.

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.

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.

Jeżeli ktoś nie poświęcił tej uwagi właśnie na dobre wyznaczenie granic tych modułów, to znowu tutaj podejrzewam, że mogło być jakieś tam, powiedzmy, nadużycie. De facto być może moglibyśmy skończyć z tym takim dosyć popularnym scenariuszem, że wiele eventów takich biznesowych de facto oznacza to samo z punktu widzenia jakby logiki biznesowej. Samo narzędzie nie jest jakoś bardzo złe albo bardzo dobre, to jest tylko narzędzie. Ja to patrzę na to, jak na takie dłutko. To może jest takie mniejsze albo większe dłutko, może niektóre typy problemów, lepiej się rzeźbi tym dłutkiem, a niektóre inne, a może trzeba i tak wiele dłutek na różne fragmenty tej samej rzeźby. A jak wygląda wsparcie dla tego rozwiązania w kontekście istniejących frameworków? Bo to, co tutaj Paweł wspomniałeś, to oznacza, no dobra, no to w sumie tylko przy zapisie muszę odesłać jeszcze raz tą kwerendę i podać identyfikator strumienia, czyli metoda save mojego event store'a po prostu musi być jakoś rozszerzona.

Paweł, dziękuję ci bardzo. Dziękuję również. I standardowo wszystkie linki oczywiście będą w opisie odcinka. Do zobaczenia.