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