How to use sagas in a CQRS architecture using DDD?

Question

I am designing a CQRS application using DDD, and am wondering how to implement the following scenario:

• a Participant aggregate can be referenced by multiple ParticipantEntry aggregates
• an AddParticipantInfoCommand is issued to the Command side, which contains all info of the Participant and one ParticipantEntry (similar to an Order and one OrderLineItem)

Where should the logic be implemented that checks whether the Participant already exists and if it doesn't exist, creates the Participant?

• Should it be done in a Saga that first checks the domain model for the existence of the Participant, and if it doesn't find it, issues an AddParticipantCommand and afterwards an AddParticipantEntry command containing the Participant ID?
• Should this be done entirely by the aggregateroots in the domain model itself?

Answer 1

You don't necessarily need sagas in order to deal with this situation. Take a look at my blog post on why not to create aggregate roots, and what to do instead:

http://udidahan.com/2009/06/29/dont-create-aggregate-roots/

Answer 2

Where should the logic be implemented that checks whether the Participant already exists and if it doesn't exist, creates the Participant?

In most instances, this behavior should be under the control of the Participant aggregate itself.

Processes are useful when you need to coordinate changes across multiple transaction boundaries. Two changes to the same aggregate, however, can be managed within the same transaction.

You can implement this as two distinct transactions operating on the same aggregate, with coordination; but the extra complexity of a process doesn't offer any gains. It's much simpler to send the single command to the aggregate, and allow it to decide what actions to take to maintain the correct invariant.

Sagas, in particular, are a pattern for reverting multiple transactions. Yan Cui's How the Saga Pattern manages failures with AWS Lambda and Step Functions includes a good illustration of a travel booking saga.

(Note: there is considerable confusion about the definition of "saga"; the NServiceBus community tends to understand the term a slightly different way than originally described by Garia-Molina and Salem. kellabyte's Clarifying the Saga Pattern surveys the confusion.)