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