21

I'm trying to understand sagas, and meanwhile I have a specific way of thinking of them - but I am not sure whether I got the idea right. Hence I'd like to elaborate and have others tell me whether it's right or wrong.

In my understanding, sagas are a solution to the question of how to model long-running processes. Long-running means: Involving multiple commands, multiple events and possibly multiple aggregates. The process is not modeled inside one of the participating aggregates to avoid dependencies between them.

Basically, a saga is nothing more but a command / event handler that reacts on internal and external commands / events. It does not contain its own logic, it's just a (finite) state machine, and therefor provides tasks such as When event X happens, send command Y.

Sagas are persisted to the event store as well as aggregates, are correlated to a specific aggregate instance, and hence are reloaded when this specific aggregate (or set of aggregates) is used.

Is this right?

hdoghmen
  • 3,175
  • 4
  • 29
  • 33
Golo Roden
  • 140,679
  • 96
  • 298
  • 425

3 Answers3

9

There are different means of implementing Sagas. Reaching from stateless event handlers that publish commands all the way to carrying all the state and basically being the domain's aggregates themselves. Udi Dahan once wrote an article about Sagas being the only Aggregates in a (in his specific case) correctly modeled system. I'll look it up and update this answer.

There's also the concept of document-based sagas.

stratovarius
  • 3,720
  • 1
  • 30
  • 26
Dennis Traub
  • 50,557
  • 7
  • 93
  • 108
  • 1
    This would be great :-)! Thanks for your efforts! – Golo Roden Nov 21 '12 at 09:53
  • 2
    Is the article still available somewhere? The link is broken now and I'm very curious about the content. – Pinyin Jun 07 '15 at 03:00
  • 3
    Apparently, the article was retracted by Rinat Abdullin himself: https://twitter.com/abdullin/status/632157086638546944 – koenmetsu Sep 30 '15 at 14:11
  • 1
    does anyone have any reference to Udi Dahan talking about it? This is a very confusing subject due to different people describing Saga as something else. MSDN makes a difference between Saga and Process Manager where Process Manager is a transaction orchestrator within a bounded context and Saga within more than one bounded context. Nothing about compensating actions though. I've always called this concept "Policy", something that reacts to an event by starting new transactions. If there are "transactions" across different bounded contexts, I'd say the context mapping must be wrong. – diegosasw Sep 24 '20 at 13:34
7

Your definition of Sagas sounds right for me and I also would define them so.

The only change in your description I would made is that a saga is only a eventhandler (not a command) for event(s) and based on the receiving event and its internal state constructs a command and sents it to the CommandBus for execution.

Normally has a Saga only a single event to be started from (StartByEvent) and multiple events to transition (TransitionByEvent) to the next state and mutiple event to be ended by(EndByEvent).

On MSDN they defined Sagas as ProcessManager.

Jehof
  • 34,674
  • 10
  • 123
  • 155
  • Great :-). I am just asking myself why there is always such a "very special" flavour in the air when talking about sagas, if they are nothing else but command-emitting event handlers - but that's fine for me, and it makes sense :-). Thanks! – Golo Roden Nov 21 '12 at 09:47
  • And sometimes a saga can react on event by interacting with external service. Send an email for instance. – Eugene Feb 14 '17 at 05:00
3

The term saga is commonly used in discussions of CQRS to refer to a piece of code that coordinates and routes messages between bounded contexts and aggregates. However, for the purposes of this guidance we prefer to use the term process manager to refer to this type of code artifact. There are two reasons for this: There is a well-known, pre-existing definition of the term saga that has a different meaning from the one generally understood in relation to CQRS. The term process manager is a better description of the role performed by this type of code artifact. Although the term saga is often used in the context of the CQRS pattern, it has a pre-existing definition. We have chosen to use the term process manager in this guidance to avoid confusion with this pre-existing definition. The term saga, in relation to distributed systems, was originally defined in the paper "Sagas" by Hector Garcia-Molina and Kenneth Salem. This paper proposes a mechanism that it calls a saga as an alternative to using a distributed transaction for managing a long-running business process. The paper recognizes that business processes are often comprised of multiple steps, each of which involves a transaction, and that overall consistency can be achieved by grouping these individual transactions into a distributed transaction. However, in long-running business processes, using distributed transactions can impact on the performance and concurrency of the system because of the locks that must be held for the duration of the distributed transaction.

reference: http://msdn.microsoft.com/en-us/library/jj591569.aspx

nologo
  • 5,918
  • 3
  • 36
  • 50