DDD - Modify more than one Aggregate in the same transaction

Question

I’m a beginner in DDD and came across a situation involving the rule of not modifying more than 1 Aggregate in the same transaction, using Domain Events to resolve changes in other Regattas. (see Effective Agregate Design).

The situation is as follows: The user schedules the transfer of a patient to another unit. When the transfer time comes, the user selects it in a list and clicks 'start'. But this action entails changes in three regattas (process raised with the customer):

• Download: is marked as started. ex: transfer.Start();

• Patient: is marked as in transfer. ex: patient.Marcarcomoemtransference();

• Unit: you must reserve a position for the patient who is now to come. ex: unit.Reservarvaga(patient);

Once the transfer is started, a Transfer event is issued. Also at this time the team is authorized to start it. But if for some reason, the team initiates the transfer, but there is an error in treating the Transference event initiated, for example, by changing the patient’s status or booking a vacancy at the destination, how should I deal with this situation, since the team may already be in the middle of the transfer?

Remembering that I am following the rule of a transaction by Agregate.

Answer 1

First of all it is important that you define the order in which events occur. Should the transfer start before the reservation? Shouldn’t there be a vacancy check before? That said, in my view, booking the vacancy should come before the transfer.

With the vacancy reserved, the user can receive a notification that the transfer can be started or an event can be issued for a subscriber to initiate the transfer.

The second case - patient in transference - can occur through the event of transference initiated. The event publisher should know how to deal with possible flaws in the delivery of the message. This will depend on the Broker message you are using. Most have a Feature to handle this. The most common is to add the failed message in a retentative queue.

It is also important to check that there is no error in the modeling of the transactional boundaries of the two aggregates. The need to manipulate two or more aggregates within a single transaction may be an indication that there are gaps in their consistency limits.