notxcain
commented
4 years ago Hi! As you already said it is possible to implement stateful saga using Aecor Entity, as it allows to perform arbitrary effects during command processing. I'm open to any suggestions on how to design Saga module, preferably on top of Aecor Entity.
When it comes to entities interacting with each other, Aecor is more on a choreography side, by design. However, oftentimes I run into cases when being able to organize my code in the form of an orchestration could make it easier to reason about the data flow and simplify application's architecture significantly.
Of course, it seems that one could create a single entity with a bunch of processes (that receive events and in turn issue new commands) and make it act like a saga, to have that orchestration part with Aecor. The obvious flaw here is that we end up having loads of boilerplate, even when having a few entities to orchestrate (we need a saga entity, its own events and quite a lot of separate processes that allow us to form kind of a distributed transaction with other entities/aggregate roots).
But what if we make saga a first class citizen in Aecor? To eliminate all that boilerplate and provide a seamless experience when orchestration is one's choice. Do you think that some building blocks for a saga pattern could be a part of Aecor or should it be placed in a separate library/toolkit that leverages Aecor to deliver FP-style event sourcing for Scala?