CODEWITHSUNDEEP
domain-driven-designcqrsnservicebus-sagas
Cpt Slow
Cpt Slow

Reputation: 380

How to use sagas in a CQRS architecture using DDD?

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

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

Upvotes: 1

Views: 2441

Answers (2)

Udi Dahan
Udi Dahan

Reputation: 12057

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/

Upvotes: 5

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57257

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.)

Upvotes: 1

Related Questions