Tuesday, 2 November 2010

Domain Events Rock!

It seems nowadays that the answer to many of our architectural conundrums are answered over atUdi Dahan's blog. He certainly has a habit of hittings the heads of nails.
The latest pattern of his we have been using is Domain Event. Here are some of the uses we have found for this pattern

Decoupling between bounded contexts within your application

You may have heard or read about the idea of bounded contexts. As an application grows it becomes very difficult to picture it as a whole and keep the whole thing in your head. Before you know it it becomes hard to understand the dependencies between the area of the app you are working on and other areas. There are many links to objects in other areas which makes your code fragile as other people refactor their areas. One answer to this is to denormalise any information required from another area of the application into properties of objects in this area. However, this leaves you with the issues of how to keep this denormalized information up to date. Domain events!

Avoiding injection of repositories etc into the domain model

You want to keep the logic in the domain. A method on a domain object does something which then has a knock on effect on somewhere else in the model which this domain object doesnt have a referenece too. Raise a domain event! The event handler that handles this is created via the IOC container so can get the required object from the repository and act on. An example of this interaction might be Order raises a OrderDispatched domain event which is handled by the UpdateStock : Handles class. This then gets the correct stock item and decrements it.

Emails everywhere

You want to send notification emails at all sorts of points in your application. You want to manage these, and what causes them all in one place. Once again... you guessed it. You can have a part of your application just for sending emails with a handler for any domain event you want to send an email for. This provides great visibility of what emails are sent and why. And also means you can easily add additional email notifications to the system without having to touch the calling code.

In addition to this, you can easily start to implement a CQRS-like architecture over time by updating reporting views from the domain events either synchronously or asynchronously for areas of the application which are slow to report on.

All in all, very handy!


  1. Your post is focused on a business. It is so effective for thoes people who is intreasted on business.

  2. this is exactly what I was looking for.thanks for the valuable tips. Keep blogging.

  3. I also liked your post but the best part that interested me is the one under the hear "Avoiding injection of repositories etc into the domain model".Good job man!