Trudność w implementacji Event Driven Architecture

Cześć, przerabiam sobie jakiś tutorial na temat event driven architecture (Saga) i im dalej w las tym wydaje mi się, że nie ogarniam i ta koncepcja to jest jakiś wielki burdel, gdzie mamy kilka tych samych klas (POJO z dodatkami), ale różnie nazwanych typu CreateProductCommand, ProductAggregate, ProductEntity, CreateProductRestModel, ProductLookupEntity (potrzebne do sprawdzenia event store), ProductCreatedEvent i w pakiecie query ProductRestModel :/

Do tego nie ma żadnej płynności w kodzie, w sensie, że normalnie wiesz gdzie leci request i po kolei wiesz które metody się wywołają, a tutaj masz tylko nadpisane metody void handle z jakąś adnotacją np. @ CommandHandler w różnych warstwach i cholera wie, kiedy się to wywoła.

To jest serio takie wymagające, czy o co tu chodzi?

Czy przy mikroserwisach jest to konieczne, czy jest jakaś alternatywa?

Znalazłem w google jeszcze taką odpowiedź:
Three commonly quoted disadvantages of event-driven architecture are:
Increased complexity.
Debugging and troubleshooting challenges.
Difficulties with monitoring

Jakie są Wasze doświadczenia?

Dokładnie tak jest. Dlatego architektury jak zdarzeniowa, mikrouslugowa, oparte o taktyczne techniki DDD powinny być stosowane tylko tam gdzie zysk biznesowy bedzie wyzszy od kosztow poniesionych na ich implementacje. A koszt jest nie maly co sam zauważyłeś. Dlatego też najczęściej mają sens w naprawdę dużych aplikacjach obsługujących dziesiątki tysięcy do milionów użytkowników.

Popatrz jak zaczynały takie firmy jak Netflix, Amazon czy lokalne Allegro. Na samym początku działalności były to aplikacje monolityczne z dużą ilością spaghetti i swoimi problemami. Dopiero ich wzrost w skali biznesowej wymusił na dzialach IT migrację w kierunku architektur rozproszonych żeby sprostać wymaganiom biznesowym i żeby im się to opłaciło. Jak widzę aplikację gdzie ktoś zaczyna od mikroserwisow mając kilkunastu a czasem nawet nie mając jeszcze żadnego użytkownika to mysle <papież macha>.jpg

markone_dev napisał(a):

Jak widzę aplikację gdzie ktoś zaczyna od mikroserwisow mając kilkunastu a czasem nawet nie mając jeszcze żadnego użytkownika to mysle <papież macha>.jpg

A to nie jest tak, że tworząc projekt lepiej na początku podjąć decyzję odnośnie architektury bo później zmiana (monolit -> mikroserwisy) jest bardziej czasochłonna niż napisanie tego od nowa?

steeve napisał(a):

markone_dev napisał(a):

Jak widzę aplikację gdzie ktoś zaczyna od mikroserwisow mając kilkunastu a czasem nawet nie mając jeszcze żadnego użytkownika to mysle <papież macha>.jpg

A to nie jest tak, że tworząc projekt lepiej na początku podjąć decyzję odnośnie architektury bo później zmiana (monolit -> mikroserwisy) jest bardziej czasochłonna niż napisanie tego od nowa?

Nie.

Architektura powinna się wyłonić na podstawie wielomiesięcznej pracy z klientem, kiedy będzie więcej informacji nt tego jak aplikacja konkretnie działa.

Podjęcie takiej decyzji na początku projektu, zanim dostaniesz jakiekolwiek informacje na podstawie jakiegoś takiego gdybania, to bardzo słaby pomysł.

@steeve: weź przestudiuj case study firm które są uważane za innowacyjne w dziedzinie wprowadzania nowych technologii i rozwiązań to znajdziesz odpowiedź na swoje pytanie.

Tak ,zmiana z monolitu na mikroserwisy jest trudna, nie ma co do tego wątpliwości. Zapominasz tylko (z reszta nie tylko ty ale wielu programistów i architektów IT) o tym że architektura IT jest odzwierciedleniem potrzeb biznesowych a szczególnie jego ewolucji.

Znaczy to tyle że jeżeli dopiero zaczynasz ze swoim produktem i jeszcze nie wiesz czy osiągniesz poziom milionów użytkowników to na początku zaczynasz od tego by swój produkt dostarczyć na rynek jak najszybciej, najlepiej przed konkurencją. Jezeli zaczniesz od skomplikowanych rozwiązań to zamiast generowac wartosc biznesowa to bedziesz tracil czas na rozwiazywanie problemow w kodzie twojej aplikacji a w tym czasie konkurencja bedzie przejmowac twoich klientów.

Dlatego architekura IT powinna ewoluowac wraz z rozwojem i wzrostem biznesu. Wszyscy się masturbują do pojęcia Agile w kwestii zarządzania projektem zapominając że architektura też powinna być Agile, czyli odpowiadać na zmiany. Jest nawet na to takie "mądre" pojęcie jak Agile Architecture.

Myślenie o architekturze IT jako czymś stałym i trudnym do zmiany to myślenie rodem z lat 90 i wczesnych 2000.