Should sagas have their own events?

[emragins]

Warning: I make no claims to know what I'm talking about.

Currently my sagas -- not in production or use in any way -- look something like this:

MySaga {

 Handle(Event1 ev){

  // do something 

  ApplyChange(ev);

  }

  ApplyChange(Event ev){

     // set version, etc

     this.Apply(ev);

  }

  Apply(Event1 ev){

    _state = Started;

  }

}

I'm wondering if instead MySaga should make it's own personally-relevant copy of Event1 -- which may even be MySaga.Event1 -- because when the saga gets saved, all its events go into the event store, and then read again and re-published out to all the exact same subscribers that just received the first version of the event.

Ultimately this isn't "bad" so long as the event is something from which responders overlay data -- any sort of running count would be out.

So.. best practice: 

Should sagas have events created just for them to track internal state?

[Danil Suits]

You and I seem to be at about the same point in the learning curve: take the following with a lick of salt.

Should sagas have events created just for them to track internal state?

 
I believe the answer is yes.  There are a few different arguments to be made, but I think the critical one is this: the details of process life cycles are likely to be very interesting to the business.  Imagine a view (projection) that shows all processes which are currently running (started, but not yet completed).  How do we pick that signal out of an event stream if the process managers are merely duplicating events into their own stream?

There's the additional riddle that some process managers are created in response to events published by some other bounded context.  I'm pretty wary of publishing *your* events in *my* stream, because nobody should be treating me as the book of record for your aggregates.

What about versioning?  In an aggregate, commands and state are decoupled; you can easily change the behavior of the aggregate without changing its current state.  Can you still do that in a process manager if the (incoming) events and state are tightly coupled?

[Danil Suits]

Related thought: if the process managers are writing their own events, they are also writing their own event metadata, which I believe is a desirable thing.

[Ben Kloosterman]

Many Sagas are Aggregates just Saga: Aggregate so you use the same persistance etc

The only disadvantage is these event can be of a more techical rather than a business nature though should try to keep them business meaningful. 

Ben

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[emragins]

Wow... so in reading your responses I've started to revise how I think of sagas.

The use case I'm currently trying to tackle is the state of an object changes -- such as an application being submitted -- and I want to let the business know.   But I don't want the aggregate responsible for sending emails, and I want to make sure they only happen once: enter a saga.

I was planning to store the ApplicationSubmitted event directly in my saga's stream, but after reading what you all are saying about Business Process, an ApplicationSubmittedEmailSent event may be more appropriate.  Or perhaps a more generic ApplicationNotificationSent(id, state) would probably suffice.  I'm resisting the temptation to just call it NotificationSent(id, type, state) since then it beckons having to look inside to gain real meaning -- "Was that an Application or a Change Request?"

And all of a sudden things are just a little bit clearer in every way, where clarity breeds awareness of ones ignorance.

Thanks, everyone.

[Antony Koch]

I would be inclined to say that your saga/process manager receives domain events, and does so because most likely you need to effect changes against more than one aggregate. This is done via commands, so Event -> Command(s). If you are raising events specifically for your saga to capture, I would say you aren't modelling your domain or events correctly.