Saga design

Imported from Google Groups
#1

I see two different ways of designing saga. What design will
axonframework support

1) Separate handlers from saga
http://jonathan-oliver.blogspot.com/2010/09/cqrs-sagas-with-event-sourcing-part-ii.html
public interface ISaga
  {
    Guid Id { get; }
    long Version { get; }
                                // handler call Transition
    void Transition(object message);

    ICollection GetUncommittedEvents();
    void ClearUncommittedEvents();

    ICollection GetUndispatchedMessages();
    void ClearUndispatchedMessages();
  }

2) Saga with handler
http://www.udidahan.com/2009/04/20/saga-persistence-and-event-driven-architectures/

       public class ShippingSaga : Saga<ShippingSagaData>,
           ISagaStartedBy<OrderAccepted>,
           ISagaStartedBy<CustomerBilledForOrder>
       {
           public void Handle(CustomerBilledForOrder message) {
               this.Data.CustomerHasBeenBilled = true;
               this.Data.CustomerId = message.CustomerId;
                    this.Data.OrderId = message.OrderId;
                        this.CompleteIfPossible();
             }

#2

Hi Steve,

the implementation I am planning to provide will look like the second one you sent. They will use the same event handling mechanism as event listeners and aggregates, and will provide the same annotation support.

Cheers,

Allard

#3

i'd also vote for the second one (by Udi Dahan);

<imho>the first one exposes to many implementation details</imho>

g,
kris

#4

In case of second implementation ,will saga be part of infrastructure
component? As saga handle’s event and command that belong two or more
module.

example :
let's image that I have created different package for a module like
module-command, module-commandhandler, module-domain , module-event ,
module-infrastructure(has eventhandler,repo impl),module-
queries,module-shared,module-ui.

Were will saga (example ShippingSaga , ShippingSagaData)be packaged or
which layer it will belong to? . Do we need a separate module called
module-saga?

#5

hi steve,

i'd put the commandhandlers, sagas and domain objects (entities, AR)
into one single domain module. commands and events would remain in
separate modules so they could be referenced by others without risking
circular dependencies. furthermore i'd put the repository there too
because only this module schould be able to create/read my domain
objects directly

g,
kris

#6

Hi Steve,

my module layout looks similar to that of Kristian. The command processing component, which contains the command handler and domain objects, is one component. This module also contains the configuration of the aggregate repositories (there is no specific class for it, since I use the GenericEventSourcingRepository). This component can be seen as the core of the application itself.

Then I have the “API” module, which contains the commands and events, and also the configuration of the commandbus and eventbus. This is the module that defines how components can interact with your application.

The query modules are separate modules. These contain the event handlers and repositories that provide the dto’s. Note that every specific type of UI, e.g. admin, end-user frontend, reporting, etc) might have a different query module, so there could very well be more than one.

Saga’s are a different story. In some cases, I put them in the module with the command handler. However, if a Saga becomes larger and manages activity between more components, you should consider separating it into another module. This typically only happens in larger applications that has more than one bounded context.

Hope this helps.

Cheers,

Allard