Show Notes
W informatyce są tylko dwie trudne rzeczy: unieważnianie pamięci podręcznej i nazywanie rzeczy... A jeśli mówimy co systemach rozproszonych, to do tej krótkiej listy Phila Karltona należy dopisać jeszcze skuteczną komunikację sieciową. Projektując systemy często zapominamy o tym, jak zawodny może być to komponent. A złośliwie zawiedzie pewnie w bardzo ważnym momencie... Na szczęście możemy temu zapobiec korzystając z wzorca Transactional Outbox.
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.