Domain events

In software development, each use case involves a set of functions designed to achieve a specific scenario. To implement this scenario, two main approaches can be used: controlling the sequence of operations to achieve the desired outcome or relying on domain events that arise from the underlying business logic of the system to guide the necessary steps. In this article, we will explore how domain events work, their advantages and disadvantages, and when and how to effectively leverage them in software development.

1. Orchestration Workflow

This approach means that you control the order in which things happen to achieve your goal. For example, let's say you have two tables: employees and families. If you want to delete an employee, you also need to delete their family records. Here's what that might look like:

In this case, everything happens in a specific order, and the application layer (the part of the code that handles the actions) manages it. But if you think about it, deleting employee family records is also a business decision. Dealing with that directly in the application layer would confuse things a lot. This is where Domain Events can help.

2. Domain Events

With domain events, the domain (basically your core business logic) raises an event when something happens, and the application layer doesn't need to worry about how it's done. Let's use the same example but with domain events:

First, we update the domain model to handle the event:

Now, the application layer doesn't need to do much, just call the business logic and let the scope handle it:

In this approach, the domain layer raises events, and the application layer only triggers the relevant business logic. For example, deleting an employee’s family is handled as part of a domain event. This ensures a clearer separation of concerns, promoting the single responsibility principle.

In the end, the domain events must be handled, usually in your database context or through middleware in an asynchronous manner. But This can add complexity to your system. For example, if you're using asynchronous handling in middleware and something goes wrong and your domain event fails, you need to define a recovery strategy to ensure consistency. This complexity might make orchestration a simpler and more appropriate choice in some cases.

Pros and Cons of Domain Events

Domain events work well in microservices, especially when combined with messaging systems like RabbitMQ. You can receive events from a message broker, convert them to domain events, and trigger the necessary actions in your application without worrying about who implements the logic. A single piece of code can handle these events across different services.

Final Thoughts

There are pros and cons to using domain events or event sourcing. The key question is when and how to use these approaches, especially in systems with multiple teams where each team owns a specific piece of the business logic. Domain events can provide powerful separation but may introduce complexity that needs to be carefully managed.