-
Notifications
You must be signed in to change notification settings - Fork 460
Adv2 Scenarios
Here are the diagrams and accompanying text that we showed you in the advisory.
The scenario, kept deliberately simple, from the Conference Management System is:
- People want to book seats for a conference.
- The system needs to check that seats are available.
- The system needs to save details of the booking.
- The system needs to update the count of booked seats.
The scenario is not intended (yet) to match the current implementation - it is intended to illustrate a range of possible implementation approaches and suggest what types of questions you should be asking when you are evaluating which approach to take.
You can see the diagrams on these Wiki pages:
The team identified these questions about these approaches:
- Where does the validation that there are sufficient seats for the registration take place, in the Order or ConferenceSeatsAvailability aggregate?
- Where are the transaction boundaries?
- How does this model deal with concurrency issues when multiple registrants try to place orders simultaneously?
- What are the aggregate roots?
The following sections discuss these questions in relation to the three approaches considered by the team.
Before a registrant can reserve a seat, the system must check that there are enough seats available. Although logic in the UI can attempt to verify that there are sufficient seats available before it sends a command, the business logic in the domain must also perform the check because the state may change between the time the UI performs the validation and the time the command is delivered to the aggregate in the domain.
In the first model, the validation must take place in either the Order or ConferenceSeatsAvailability aggregate. If it is the former, the Order aggregate must discover the current seat availability from the ConferenceSeatsAvailability aggregate before the reservation is made. If it is the later, the ConferenceSeatsAvailability aggregate must return a success or failure code to the Order aggregate.
The second model behaves similarly, except that it is Order and ConferenceSeatsAvailability entities cooperating within a Conference aggregate.
In the third model, with the saga, the aggregates exchange messages through the saga about whether the registrant can make the reservation at the current time.
All three models require entities to communicate about the validation process, but the third model with the saga appears more complex than the other two.
An aggregate, in the DDD approach, represents a consistency boundary. Therefore, the first model with two aggregates, and the third model with two aggregates and a saga will involve two transactions: one when the system persists the new Order aggregate, and one when the system persists the updated ConferenceSeatsAvailability aggregate.
To ensure the consistency of the system when a registrant creates an order, both transactions must succeed. To guarantee this, we must take steps to ensure that the system is eventually consistent by ensuring that infrastructure reliably delivers messages to aggregates.
The second approach that uses a single aggregate, we will only have a single transaction when a registrant makes an order. This appears to be the simplest approach of the three.
The registration process takes place in a multi-user environment where many registrants could attempt to purchase seats simultaneously. The team decided to use the [reservation pattern][res-pat] to address the concurrency issues in the registration process. In this scenario, this means that a registrant initially reserves seats (which are then unavailable) for other registrants; if the registrant completes the payment within a timeout period, the system keeps the reservations; otherwise the system cancels the reservation.
This reservation system introduces the need for additional message types, for example an event to report that a registrant has made a payment, or report that a timeout has occurred.
This timeout also requires the system to incorporate a timer somewhere to track when reservations expire.
Modeling this complex behavior with sequences of messages and the requirement for a timer is best done using a saga.
In the two models where there are the Order aggregate and the ConferenceSeatsAvailability aggregate, the team easily identified the entities that make up the aggregate, and the aggregate root. The choice is not so clear in the model with a single aggregate: it does not seem natural to access orders through a ConferenceSeatsAvailability entity, or to access the seat availability through an Order entity. Creating a new entity to act as an aggregate root seems unnecessary.
- Do the approaches make sense?
- Should we include other alternative approaches?
- What other interesting questions should we be asking when we evaluate the approaches?
- Is this type of discussion about alternatives and trade-offs useful?