DevTalk #138 – O Event-Driven Architecture z Tomaszem Stolarczykiem

I zresztą to nam też powinno się gdzieś jakoś kojarzyć, że jeśli ktoś gdzieś tam jeszcze, tutaj jest z Javowego świadka, gdzieś tam w Swingu takie aplikacje UI-owe robił. To też zauważał takie to odwrócenie tej zależności, ale nie powiedziałbym, że to jest właśnie Event-Driven Architecture. Ja bym poszedł troszkę dalej właśnie, jeśli mielibyśmy to sobie tłumaczyć, bo po co byśmy chcieli w ogóle sobie Event-Driven... To głównie takimi moimi driverami w tym kierunku to jest to, że jednak chcielibyśmy mieć jakiś taki decoupling, prawdziwy decoupling między producentem a subskrybentem. Autonomiczność tych subskrybentów, którzy będą sobie działali i w sumie nawet ich skalowalność na tym poziomie, że nawet obsługa konkretnego zdarzenia, ten worker, który to robi, że też moglibyśmy samych workerów, czyli tych konsumentów skalować bardzo

Konsekwencje i o tym chyba będziemy dzisiaj też mówić. No na pewno, ale chciałbym zatrzymać się przed tym co powiedziałeś, że nie wszystko co zawiera w sobie jakieś tam eventy od razu można nazwać event-driven architecture, no bo eventów w sumie tak naprawdę te 15 lat temu ten wysyp taki się zaczął, poza faktycznie tymi eventami w UI. Ty mówiłeś o Swingu, ja to bardziej np. byłem w Microsoft Forms, w dotnecie. Jak to się nazywało? .NET Forms? Windows Forms, o właśnie. I ITP, inne różne desktopowe wariacje. Mamy SQL REST, gdzie są eventy i są komendy, gdzie jest ten podział. Jest event store, gdzie można eventy przechowywać. Z tego bierze się event sourcing, co nie? Które te eventy potem można sobie odtwarzać. Ale mamy z zupełnie innej beczki event storming, który ma się nijak do...