Domain event handlers. Should they be used for application level issues?

Question

When implementing domain events, if event handlers will be used only for problems with purely domain names; What could you discuss with business experts, or are they open to use by anyone interested in a domain model?

This is most likely best explained by a simple example; look at the Calendar app for employee scheduling.

We may have the following domain events ...

AppointmentAdded AppointmentRemoved AppointmentContentChanged AppointmentMoved

We have handlers for these events, for example, when an appointment is postponed outside of the employees' working hours, we set a warning flag.

Of course, there are application problems that are interested in these events, for example. when an Appointment is added to the calendar, we must add it to the Unit of Work so that we can commit the changes later.

Should these applications be consumers of domain events, or should we raise and handle individual system events instead?

Answer 1

There are two well-known ways to use events in a DDD solution.

The first is based on an Udi Dahan event article . If you have not read them yet, I highly recommend this. The bottom line is that you post your events using a static class in addition to normal ORM style behavior. Thus, you add the order to the collection of customer orders and that you publish. Since the behavior of your domain is executed inside the transaction scope, i.e. event handlers. You can also find there and advice not to manually attach objects to the Unit of work. New population roots must be created by invoking behavior for existing ones.

There is another option that Greg Young is promoting. It is based on event search, which mainly uses events as a means of saving state. In this approach, your aggregate roots typically use some infrastructure (such as a base aggregate root class) to apply events. Apply calls the event handler in the aggregated root class and publishes this event on the bus (regardless of the bus implementation you are using).

Answer 2

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

But if you need to do several independent things when the event of your domain occurs, you better use separate event handlers (see the section "The principle of separation of problems").

In the first case, by the way, try to avoid confusing the domain logic with the event processing logic (infrastructure). The left infrastructure / intersectoral processing concerns the code in event handlers that invoke domain methods. Moving domain code inside domain object methods.