Ecotone, Saga is POPO Aggregate,
as Aggregate comes with a lot of functionality, that is used in typical Saga implementation. This provides a lot of flexibility, as Aggregate can combine behaviour of Saga and vice versa, when needed. Ecotone
does not try to impose the solution.Aggregate
- Saga can stated-stored Aggregate or Event Sourced Aggregate
EventHandler
- We mark method to be called, when specific event happens. start
- is factory method
and should construct new instance OrderFulfillment.
Depending on need you may construct differently as Event Sourced Aggregate.paymentWasDone
- Is called when PaymentWasFinishedEvent
event is published. We have injected CommandBus
into the method in order to finish process by sending ShipOrderCommand.
We could also publish event instead.PaymentWasFinishedEvent
we need to tell Ecotone
which instance of OrderFulfillment
it should be retrieve from Repository and call method on.Event
is the same as property marked as @AggregateIdentifier
in aggregate. Ecotone
a hint, how to correlate identifiers. Before
or Presend
Interceptors to enrich event's metadata with required identifier.
Suppose the orderId identifier is available in metadata under key orderNumber, then we can tell Endpoint to use the mapping.OrderWasPlacedEvent
and the second which finishes the Saga is PaymentWasFinishedEvent.
It it's always risky to make such assumptions, especially, when events comes from different systems.
What we could do instead, is to expect them to come in different order and handle it gracefully.startByPlacedOrder
and action method whenOrderWasPlaced
are handling the same event.
If that's the case, Ecotone will verify, before calling factory method, if the aggregate exists and if so, will reroute the event to the action method.
This solution will prevent us from depending on the order of events, without introducing routing functionality into our business code.whenNewOrderWasPlaced
method.