[Someguy3517372]

Kurcze, 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 #!$%@? 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

#programista15k #programowanie #naukaprogramowania #java #spring

[laypokahontaz]

@Someguy3517372: wszystko zależy od projektu jaki masz, weź pod uwagę, że wszystkie te przykłady itd są na wymyślnej przez kogoś domenie, która wymagania ma idealne pod DDD. Niestety często w korpo domena jest bardziej skomplikowana i wtedy zaczyna być jeszcze większy syf :)

Prawda jest taka, że będziesz miał w #!$%@? plików: value objecty, mappery, service, domain service, domain, handlery, repository, eventy a i tak pewnie na końcu okaże się, że