DOMAIN EVENTS | Domain Model | Domain Layer | Domain Driven Design

Domain Events | Domain Model | Domain Layer | Domain Driven Design

Domain Events:Domain events can be used to model distributed systems. The model will become more complex, but it can be more scalable. Domain Events are often used in an Event Driven Architecture Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services.

Domain Events

• Domain events are significant occurrences in the real-world problem domain; they are part of the ubiquitous language (UL).
• Unlike messaging between bounded contexts, domain events are applied inside a single domain model and are usually synchronous.
• Handlers in the domain carry out domain logic.
• Handlers in the service layer normally take some of the responsibilities otherwise handled by application services.

Domain Entity

Looking into a given domain, you quickly realize that there are some facts that are specifically important to subject matter experts. For example, they can introduce these facts using such phrases as:

• When...
• If this is the case...
• Contact me if...
• In case of...

That is, if something is due to happen following other action, you need to design a specific domain entity.

In the process you should pay special attention to the fact that domain entity is basically any action that took place in the past. Therefore, its name should reflect that the action was in the past but is now attributed through ubiquitous language within bounded context.

Similar to value objects, domain entities are designed against any modifications; their functions are side-effect free functions. Domain entity is designed as an object the interface of which specifies its function, while its properties — the cause. 

Let’s look at FundsDeposited example below:

occuredOn is a time tag for domain entity. Then, you need to specify important properties that store the information about what’s going on (the process). One of the most important properties is an identifier of entity and aggregate, in which accountId domain entity is generated. Also, subscribers may find specific parameters that transfer aggregate from one state to the other.

In this case, we design a domain entity, which is activated when anyone credits an account. Hence, you can text a message (when the money are on the account), email or perform any other type of operation.

To publish and process domain entities, you can use observer pattern, or publisher subscriber. If the action is processed within a given bounded context, you can't use multiple infrastructure components and elements that shouldn’t exist in the borders of this or that domain. You can simply add observer pattern to the design.

That is, you can just create DomainEventPublisher object that will store, register all the subscribers and publish domain entity. The publication for subscribers is managed in sync, within a specific cycle and a specific transaction. Basically, every subscriber can process his or her domain entity separately.

It is important to stress that domain entity is a concept that exists within domain, not as a separate bounded context. So, you can transfer domain entities asynchronously into external bounded contexts, which is done thanks to built-in message communication system.

There are many components to transfer messages that are related to middleware class (e.g. RabbitMQ, NServiceBus). You can also transfer messages with REST where autonomous systems refer to the publication system, demanding non-processed notifications.

RESTful approach to the publication system of domain entity is opposed to the publication process, which is done with the help of a typical message communication structure. “Publisher” doesn’t support several types of registered “subscribers” because the interested parties don’t receive any messages whatsoever. Instead, this approach relies on REST clients to demand requests with URI.

It is crucial to understand that you need to achieve some type of coherence between the things that message infrastructure publishes and the actual state of domain. You need to guarantee that domain entity is truly transferred and that this domain entity depicts the true state of the model where it is published.

There are different methods to guarantee that this type of coherence is properly achieved. As a rule, you can rely on repository within bounded context. This repository is mainly used by the domain’s design patterns and utilizes external components that publish unpublished domain entities using the message transfer mechanism. However, this approach presupposes that clients need to deduplicate incoming messages to guarantee in case of message resend the clients can process it correctly.

In both cases, when subscribers use middleware to transfer messages, or when they rely on REST, you need to track all the processed message IDs and store all the info on changes and modifications in domain’s local state.

Domain Events

Normally, batch processes are used that try to detect state changes that occur in a certain time interval in the domain model, by means of large queries in the database, to subsequently carry out the pertinent actions through heavy transactions and data modifications. Normally long and expensive night processes.

The Domain Events , capture and notify a certain event within the domain model by means of information represented in an object. So we can perform the relevant actions or apply a given result at the same time that the change of state happens, avoiding accumulating them in time waiting to be detected by such heavy and long night processes.

The events that have taken place or changes in the status of entities or events can be stored as they happen in order to have an event history, thus applying Event Sourcing . In addition, they facilitate the integration of Bounded Contexts by decoupling structures or systems within an organization.

All events should not be considered as events to be reported in the domain model, advising to speak carefully with the domain experts to identify them correctly. Events must be part of the ubiquitous language.

The objects that store the information of an event must be verbs in the past with the minimum advised property of OccurrenceOn with the exact date / time of when it happens and it notifies. We will also need the necessary information related to the event, such as the identifiers of the entities that make up the aggregate. Events are normally designed as immutable in the same way as a Value Object . Although they are immutable, in some cases it is necessary to establish an identifier to the event.

Command Operation: Backlogitem # CommitTo 
Event outcome: BacklogItem Committed .

Command Operation: Backlogitem # PlanTo 
Event outcome: BacklogItem Planned .

Source: Modeling Aggregates with DDD and Entity Framework .

We must have one or more middleware that manages the events, either by messaging following publish-subscribe pattern or by REST API (by means of an endpoint the GET is made by packages according to the state to list the notifications of the clients that publish the events in the same API ).

There are several messaging tools that will allow us to work with events in a simple way, adopting the eventual consistency : RabbitMQ, Akka , NServiceBus , MassTransit .

The fundamental rule on which to base to avoid making several transactions in the same event, is to modify a single aggregate for a single transaction made . In said aggregate transaction, the states of all the associated entities can be modified through their identifiers informed in the event. Since it is an eventual consistency and not immediate, we assume a delay in the result of the transaction. Although there are various techniques to avoid influencing the user experience.

Normally the events are published in the methods of aggregates or entities in the domain model or in domain services , saving them if necessary in the corresponding Event Store . All this through the messaging infrastructure according to the middleware that we use in each case. On the other hand, the event subscription is made and recommended in the application services , who will handle the transaction to be carried out since it is an application concept as long as it does not concern other Bounded Context .

Source: Event sourcing the past and today .

The Domain Events can be used for the integration between Bounded Context, moving away from the application concept in the local Bounded Context. In this way it would be necessary to register the subscriptions to events generated in other Bounded Context in the domain services instead of subscribing them in the application services.

Event Store / Event Sourcing

Keeping all domain events stored we will enjoy the following advantages:

• The possibility of having a feed through a REST API of notification to clients
• Examine and have a history of changes in status that can help us with the debug and control / tracking of incidents .
• Analyze the data to determine the behavior and activity of our users or other relevant aspects that will help us in making decisions.
• Produce screenshots for each change of state, which will allow us to reconstruct aggregates or an instance at a specific moment in time. Being able to force new events and changes of state to solve bugs within our Event Stream .

The serialization of the event is the recommended technique and most used for the storage of all event information in the corresponding Event Store .

Event de-duplication

In certain scenarios it might be necessary to check the duplication in the reception of the published messages, since they could be sent and processed more on more than one occasion. To prevent the consequences, given this scenario / context, it is necessary that the transactions are carried out by idempotence operation and can be executed more than once with identical results. You can identify and detect events by a specific field or detect duplications of events through versioning.

Recommended readings:

Performance with Domain Events, Projections and principles of CQRS 
Domain Events and Eventual Consistency 
Domain Events - Domain Events allow you to segregate the models of different systems 
Domain Event - Martin Fowler 
Vaughn Vernon on Microservices and Domain-Driven Design

In previous episodes ...

Domain-Driven Design. Episode I. Starting ...
Domain-Driven Design. Episode II. Context Maps
Domain-Driven Design. Episode III Domain-Driven Design architecture
. Episode IV. Entities & Value Objects

Domain events, representing something that has happened in a domain, were not defined as a Domain-Driven Design (DDD) pattern when Eric Evan's original DDD book was released but are now a tactical element in DDD and a full member of domain models. Eventual consistency is a design approach for improving scalability and performance and domain events can help in achieving this by acting as a trigger carrying domain information, Florin Preda explains in a recent blog post.

In a transactional consistency workflow, familiar to most developers, a client executes a command on a system which then runs all operations required to maintain the domain consistency inside a transaction. When the client gets the response either all operations have succeeded or all have failed, there is no middle ground.

In an eventual consistency workflow, common in distributed systems, a client executes a command on a system but only a part of all operations required to maintain the domain consistency is run inside a transaction. The rest of the operations are run at a later time, after which time the system will be consistent.

Preda notes that although transactional consistency seems more straightforward and easier to use, there are scenarios where he thinks eventual consistency has an advantage. Using two operations, A followed by B, as an example he describes four such scenarios:

1. Operation B takes a long time to execute.
2. Operation B is asynchronous by nature, i.e. depends on an asynchronous mechanism.
3. Operation B is performed against a different aggregate than Operation A but within the same bounded context.
4. Operation B is performed inside a different bounded context than Operation A.

Scenarios 3 and 4 are for Preda related to Domain-Driven Design (DDD) and for these two he believes that choosing eventual consistency will lead to a better design compared to working with traditional transactions. This is where domain events can be helpful. They are a representation of something that happened in a domain that is relevant to a domain expert and facilitate eventual consistency by acting as triggers starting the next step in a workflow and carrying the domain information needed.

Writing about the same subject Mike Mogosanu claims that in real world use cases transactional consistency workflows are rare; a business process often involves a series of use cases and persisting a group of changes using the Unit of Work (UoW) pattern is then a naive solution complicating things from a technical point of view, especially when working in distributed applications.

Mogosanu believes that a business process involving different bounded contexts should be considered being eventually consistent with at least one domain use case per bounded context. Domain use cases are responsible for keeping aggregates consistent, and here the UoW pattern is usable, and for publishing domain events that trigger start of other use cases, eventually bringing the whole system to a consistent state.

Exemplifying his ideas Preda uses a simplified version of a design from Vaughn Vernon’s book Implementing Domain-Driven Design in an implementation of an application in C# using Azure Service Bus messaging system for transport of events.