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

Dzień dobry. Witam w kolejnym odcinku podcastu DevTalk, w którym to Tomek Stolarczyk poopowiada nam o Event-Driven Architecture. Przed Tobą DevTalk. Programistyczny głos w Twoim domu. Cześć Tomek. Cześć Maciek. Będziesz nam umilał dzisiaj dzień. Będziemy ciebie słuchać z uwagą. Więc powiedz proszę na początek kilka słów o sobie. Kogo będziemy słuchać? Kogo będziecie słuchać? W sumie w dużym skrócie, a może trochę dłuższym jednak, jestem programistą, konsultantem, specjalizuję się głównie w pracy z systemami legacy, w których pomagam wprowadzać i Domain Driven Design i właśnie temat dzisiejszego odcinka, czyli Event Driven Architecture, a w sumie to jej elementy i o tym też sobie trochę powiemy.

Właściciel Arkensy. Tutaj był, jest często, też gdzieś tam na YouTubach czy w DevTalku. I myślę, że tak z takich DevStyle'owych rejonów też można mnie kojarzyć, bo i tam gdzieś się przewijałem trochę przy DNA, Legacy Fighterze jako taki reviewer, że tak powiem, materiałów. A w Domain Drivers nawet miałem taki mały epizod, w którym byłem kuzynem Boba, tego Boba. Tego jednego.

No więc tutaj... W eventach działacie dużo. Tak, w eventach dużo działamy i faktycznie tak, jeśli mamy jeszcze też właśnie ten kontekst tych legacy projektów, to zawsze jednak musi być tak, że wiecie, nie przychodzimy i mówimy, przypisujemy wszystko, tylko trzeba jednak dobrać to rozwiązanie, wiedzieć czy się nadaje w jednym czy w drugim miejscu i też stopniowo, stopniowo. Więc tutaj zawsze gdzieś tam trzeba mieć z tyłu głowy, że to są jakby projekty, regasy. To nie jest takie wbicie i po prostu przepisujemy. To się nie nadaje. Czyli w sumie możemy przejść w takim razie do Event-Driven Architecture. Powiedziałeś, że trzeba sprawdzić czy się nadaje czy się nie nadaje. Spróbujmy może od tej strony. Powiedz czym w ogóle charakteryzuje się Event-Driven Architecture tak jakbyś wprowadzał nową osobę do swojego projektu.

Dlaczego robiłeś takie rozróżnienie, że nie każdy system, w którym mamy eventy od razu można nazwać event-driven architecture, ponieważ event-driven architecture z tego co mówisz to wpływa właściwie na całość systemu, a nie samo to, że mamy sobie gdzieś tam fruwające evenciki, które po prostu służą do komunikacji między komponentami. Dokładnie, to nie jest jakby sama taka notyfikacja, o coś tam się wydarzyło, więc wiesz, wszystko mam jakby... To wpływa na całość. Będę miał też pytanie, ale sorry, przerywałem ci, kontynuuj, a potem powiem ci, o co cię zapytam. Zapytam cię, jak w takim razie wprowadzać to do systemu, jak mówisz, że pracujecie na systemach legacy, no które siłą rzeczy pewnie w większości nie są zrobione, korzystając z Event-Driven Architecture, to jak wy to wprowadzacie powoli do systemów? Ale to zaraz. To zaraz, dobra. Bo z kolei chciałbym się odnieść do czegoś, co ty powiedziałeś, a było właśnie istotne, bo mówię to faktycznie od razu.

Jak wy to robicie, żeby konwertować ten system? Mówię, że nie jest tak, że wchodzicie, mówicie, przepisujemy wszystko, pewnie wtedy... Nikt by wam nie dawał zleceń, tylko jak do tego podejść z głową? Właśnie tutaj wracamy trochę do początku. Też powiedziałem, że my elementy nieraz, czyli to nie jest tak, że my potem robimy full flag taki event-driven architecture w całym systemie, bo to jest jakby proces faktycznie może być rozłożony. Jeśli przy takim legacy pracujemy, zaczynamy z takim legacy, to jest jakby ciężkie. I wtedy, a w sumie w każdym chyba przypadku. Nie no, przy takim legacy właśnie to jakby pierwszym takim krokiem, który ja widzę i to jest często właśnie u nas praktykowane, że jednak robimy event storming, nie?