Domain event handlers - Should they be used for Application layer concerns?

Question

When implementing Domain events should the event handlers be only used for purely domain concerns; something that you would discuss with the business experts, or are they open to be used by anything that has an interest in the domain model?

This is most probably best explained with a simple example, consider a Calendar application for scheduling work to employees.

We might have the following domain events...

AppointmentAdded AppointmentRemoved AppointmentContentChanged AppointmentMoved

We have handlers for these events, for example when an Appointment is moved to a time outside of the employees working hours we set a warning flag.

There are of course application concerns that are interested in these events, e.g. when an Appointment is added to the calendar, we should add it to the Unit of Work so we can commit the changes later.

Should these application concerns be consumers of the domain events, or should we raise and handle separate system events instead?

Legionnaire

Answer 1

There are 2 well established ways of using events in a DDD solution.

The first one is based on Udi Dahan's articles about events. If you haven't read them already, I highly recommend that. In summary it says that you publish your events using static class in addition to normal ORM-style behavior. So you add an order to customer's order collection and you publish the event. Because your domain behavior is executed inside a transaction scope, so are event handlers. You could also find there and advice not to manually attach objects to a Unit of Work. New aggregate roots should be created by invoking behavior on existing ones.

There is another option which is promoted by Greg Young. It is based on event sourcing which basically is using events as means of persisting state. In this approach your aggregate roots usually use some infrastructure (e.g. base aggregate root class) to apply events. Apply does invoke an event handler on aggregate root class and publishes this event on a bus (whatever bus implementation you use).

Damien

I doubt they promote event handling in the same transaction as the aggregate that is firing that event. As I remember Udi specifies that it's better to "fire and forget" outsite the aggregate transaction especially in the cases when event handlers have nothing to do with the domain (ex.: email messages). To "fire and forget" means that you don't care if the listener received the message, but you should care about when to fire a message (send the msg). You send a message after the aggregate has finished it's job : state change + persistence. So i sugest to fire an event after persistence. – Coolth

P.S. An event can be fired by the aggregate any time, but the actual message delivery should be handled after the aggregate persistence(or after a specific command , that triggered the event, has finished). – Coolth

Answer 2

If you mean cross-cutting concerns than you will be forced to use it anyway if your application logic requires it. So it will be mixed with other event-processing code.

But if you need to do several independent things when your domain event happened than you better to use separate event handlers (see Separation Of Concerns principle).

In the first case, by the way, try to avoid mixing domain logic with event-processing (infrastructure) logic. Left infrastructure/cross-cutting concerns code in event handlers calling domain methods. Move domain code inside domain objects' methods.

Bittencourt

this sounds reasonable, but it leads to a new question regarding when to raise the domain events. Let's say that Adding an appointment to the calendar is performed in a transaction, adding the entity to a UnitOfWork must be performed within the transaction, but updating the UI must be performed outside of the transaction. In this case, should the domain event be raised within the transaction? and the UI update should be done in another domain event handler that does it's work Async. – Legionnaire

Domain event represent something that already happened. So there should be no ability to rollback a transaction within event handler. Commit transaction then call event handlers for all events sent during transaction. – Bittencourt