Hi Benoit,
yes, sending a command directly to an aggregate based off of an Event from that same aggregate is an anti-pattern. The aggregate should be able to publish both events based on the very first command, as there is no “external” component involved.
Cheers,
Allard
Morgend Allard,
In my use case command1 sends formatted data (let's say XML) to create an aggregate from. Event1 represents a "MessageTransmittedEvent" which an event handler is registered to parse that formatted data.
Depending on outcome of parsing* a new command must be sent with either a representation of the parsed data or an error message of some kind.
If parsing fails I still need the aggregate to exist.
* parsing could imply an additional call to a remote system
How wouldntou go about to implement such situation?
Regards,
Benoît
Hi Benoit,
in this case, it’s not really an “event out, command back in” scenario, as there is an external system involved. But still, I would consider other options.
One would be to call the external system from within the Aggregate (via a well-designed interface, to prevent coupling). Not ideal, especially since the external call will be done while holding a lock on the Aggregate.
Alternatively, you could use an interceptor to fetch external data prior to executing the command. That works if the external interaction is a (side-effect free) query.
In the end, it’s three options, each with pros and cons.
Cheers,
Allard