Ready for InfoQ 3.0? Try the new design and let us know what you think!

Domain Events and Eventual Consistency

| by Jan Stenberg Follow 39 Followers on Sep 27, 2015. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Another point by Augusto Rodriguez

Sometimes having a large synchronous process can have a negative effect on user experience or business goals. For example a retail store wants to take orders and charge for them, but when you investigate further, they really care about registering the order and have an manual process to deal with a potential failed payment. If the payment fails, the order doesn't move to the 'preparing' state and someone from sales can retry the payment or contact the customer to take a new payment.

Some retailers do this and is so common that have automated systems to deal with the failed transactions.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss