Odcinek 104

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. Zupełnie jak w wierszyku o sznurku Jurka - ktoś dorzuci papierek, aż robi się góra śmieci. Jednak to tylko pretekst do tego, aby dotknąć właściwego tematu, czyli podziału między to, co publiczne, a to, co prywatne.

Diagnoza jest mniej oczywista, niż się wydaje. To nie kwestia niechlujstwa, tylko tego, że zdarzeń po prostu nie uznajemy za API naszego systemu czy jego modułów. Frontendowy kontrakt pielęgnujemy, wersjonujemy i dokumentujemy, a w przypadku eventów po często publikujemy je na Kafce czy RabbitMQ i mówimy konsumentowi “zasubskrybuj się, dane tam są”. Reszta to już seria drobnych skrótów: dopchnięte pole, synchroniczne odpytanie serwisu słownikowego, ślepo wpięty CDC, który zamiast jednego faktu wypluwa tyle technicznych updated, ile tabel ruszyła operacja.

Dobra wiadomość jeg taka, że z tego węzła da się wyjść, i to tej części poświęcamy najwięcej uwagi. Punktem wyjścia jest intencja - pytanie, czy event ma replikować stan, czy tylko zasygnalizować innej usłudze, że może działać dalej. Po drodze pojawiają się klasycy tej tematyki, czyli Gregor Hohpe i Marting Fowler, nazywanie faktów biznesowych zamiast bezpłciowego “zaktualizowano”, wzorzec Message Enrichment oraz zasada, którą warto powiesić nad biurkiem: nie każdym zdarzeniem trzeba dzielić się ze światem.