Show Notes
Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem, autorem bloga eventdriven.io postanowiliśmy przejść przez listę "antywzorców", które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing.
More from Better Software Design
Czy da się zbudować produkcyjny system o skali prawie dwóch milionów linijek kodu, korzystając wyłącznie z agentów AI i nie pisząc kodu ręcznie? Przykład Open Mercato pokazuje, że taki kierunek jest jak najbardziej możliwy i działa w praktyce, ale wymaga fundamentalnej zmiany w podejściu do procesów SDLC.
Kontynuujemy mini-serię o antywzorcach Event-Driven Architecture - ponownie z Oskarem Dudyczem. Tym razem jednak bierzemy na początek na warsztat puchnące zdarzenia: jedno “uniwersalne” zdarzenie, które próbuje zadowolić wszystkich naraz. Kolejne pole, kolejne ID “na wszelki wypadek”, aż w końcu wysyłamy w świat pół swojej bazy danych.
Zanim pójdziecie w mikroserwisy, upewnijcie się, że wasze granice są poprawne. W modularnym monolicie pomyłkę naprawicie jednym refaktorem w IDE. W rozproszonym systemie zapłacicie za to zmianami w infrastrukturze i bazach danych... Między innymi właśnie to warto zapamiętać z rozmowy z Damianem Dziaduchem, który podzielił się historią refaktoryzacji pewnego smutnego monolitu.
W poprzednim odcinku mówiliśmy o przesadnej szczegółowości eventów. Tym razem uderzamy w drugą stronę — w stronę zdarzeń-worków, które zamiast o biznesie, mówią nam tylko o tym, że "coś się w bazie zmieniło". Razem z Oskarem bierzemy na tapet CRUD-sourcing, często nazywany też obsesją stanu.