The Ordering::Order aggregate manages the state machine of an order:
- draft
- submitted
- accepted
- expired
After each successful change an appropriate event is published in the Order stream. This object is fully event sourced.
| Order | draft | expired | submitted | accepted |
|---|---|---|---|---|
| draft | ✅ | ✅ | ||
| expired | ||||
| submitted | ✅ | ✅ | ||
| accepted |
The state machine mentioned above became a very central place to the whole application. Almost every other domain either reacts to this domain or triggers Ordering.
This might be an issue, as we might end up with a God Domain.
Some of the states here are actually duplicates of the states of the Order in other domains.
We clearly have a naming issue here. What is the actual difference between submit/confirm/accept? Not all the names match between method names and event names.
We track order items here, but we actually don't really use it much.
It doesn't have any impact on the state machine.
It's only needed to some read models, which can retrieve it from elsewhere - most notably the Pricing
The implementation of Basket, because of this, seems duplicated to Pricing or Inventory.
UI -> Ordering::SubmitOrder -> Ordering::Submitted -> Reservation(process) -> Ordering::AcceptOrder
Ordering::AcceptOrder -> Ordering::OrderPlaced ->
-> Shipment::SubmitShipment -> Pricing::CalculateTotalValue
make install test mutate