Event Handlers creating Commands?

1,677 views
Skip to first unread message

Matt

unread,
Jun 15, 2011, 11:15:14 PM6/15/11
to DDD/CQRS
If I have an Event Handler that upon receiving an event needs to
perform some operation on one of my Aggregates. Should the event
handler "convert" this event into a command and send into the
'Domain' (via some sort of Bus) like any other command? Or can the
event handler directly invoke the Aggregate?

I guess what I'm indirectly asking, is should all changes to my domain
(via Aggregate root method calls) be done via Command -> Command
Handler -> Aggregate, or are there some cases where it can be done via
Event -> Event Handler -> Aggregate?

I understand it is is technically possible either way, but what is
considered the "correct" approach according to CQRS principles?

@yreynhout

unread,
Jun 16, 2011, 3:53:53 AM6/16/11
to DDD/CQRS
As a purist I'd say "send a command". Being pragmatic you could invoke
the aggregate directly, but don't start complaining when you're not
able to determine which "implicit" command caused that change to
happen.

Nuno Lopes

unread,
Jun 16, 2011, 5:23:06 AM6/16/11
to ddd...@googlegroups.com
Programming by events/facts or by commands/procecures requires in change in programming and design paradigm. If you are used to procedural reasoning rather then declarative/functional reasoning you might find the later easier.

Has for traceability it can be supported on both approaches.

If I were you, I would first get some experience with CQRS using commands as this is the dominant approach. When you crack it then move on to appreciate events as a central aspect of system design in order to enlarge you mindset.

Cheers,

Nuno

Dmitry Kryuchkov

unread,
Jun 17, 2011, 4:02:41 AM6/17/11
to DDD/CQRS
I'd send a command using saga.

Matt

unread,
Jun 19, 2011, 8:16:54 PM6/19/11
to DDD/CQRS
Yes I've just done a bit more reading about this, and a Saga seems to
fit my scenario quite well.

One thing I still don't quite understand though is how a Sage is
invoked. Does every event which maps to a Saga have its own "Event
Handler" class specifically for that Saga, similar to how each Command
is mapped to an Aggregate by a Command Handler? Or is the the "saga
handler" more generic?

The way I am currently thinking about it is like so:

1. EventA is produced
2. SagaA has subscribed to EventA
3. EventA is received by SagaAEventHandler
4. SagaAEventHandler loads up SagaA from some sort of "SagaRepository"
5. SagaA is passed details (via method call) from EventA so that it
can handle the event.

Is this the correct approach? If so, in step 5, do I pass the actual
Event object to the Saga, or do I pass only the parameters of the
Event that are needed (similar to Command -> Aggregate).

I hope this makes sense.

Aaron Navarro

unread,
Jun 19, 2011, 8:32:30 PM6/19/11
to DDD/CQRS
Also, using the command Id as a way to ensure idempotency of command
messages doesn't work with events. (which are valid when processed
multiple times by multiple subscribers)
Reply all
Reply to author
Forward
0 new messages