Modeling Cross-Entity Invariants

1. Event modeling the specifications for state changes that depend on the state of other entities is done via commands. There are a few options of keeping the story format for these specifications.

2. Event Sourcing provides a clean way of isolating online data from historic data. "Closing the books" is a strategy to ensure we don't need to repopulate using a prohibitively large data set.

3. UX/UI concerns are divided further by highlighting in blue or green where the command data comes from and where data is displayed to the user.

4. Business rules as in point 1 depend on other entities can now be illustrated in the event model by either joining that display data to the command submission in the UI, or, it can be linked to the command to show the dependency using a red arrow as this coupling is important and has many ramifications - an important one is eventual consistency.

5. Invariants that can't be broken are modeled with reservations.

6. The link from event to command - in that order - is shown to lack the important information that is the "devil in the details" of most workflow specifications omit or put a special pattern on. Here it is shown that it's composed of patterns already used in event modeling of state change and state view.

[diegosasw]

Interesting subject. But I am afraid I don't understand how the "new aggregate" solved the issue with eventual consistency in the given when then sample.

You mentioned when an order is submitted there is a view/read model keeping track of current outstanding orders, and made the Submit Order command dependant on that view/read model.
This is OK for a big percentage of cases. But this is not really protecting the invariant of "only allowing 7 orders" because, as you mentioned, if the read model/view is stale then a new order will be submitted, violating this invariant. This could happen when two orders are placed at the same time and both succeed because there were 6 outstanding orders when they checked the projection, but the result is that there will be 8 orders afterwards.

Then you mentioned that this could be fixed by adding another aggregate to enforce this invariant, by having a reservation system. But that's what got really confusing.

I can't see the suggested solution solving the original problem. Does it? It'd be great if you could ellaborate on that and how the flow would happen with these two aggregates interacting in an explicit way. Also, wouldn't that aggregate be long living and massive if it tracks reservations?