Although there is a lot of power in using microservices and reactive models, they bring with them the uncertainty of not knowing where things stand at any point in time. Message-driven systems can lead developers to often wonder about seemingly simple questions:
• Has someone received my message?
• Have they replied?
• Were messages received out of order?

Speaking during a keynote presentation at the Explore DDD conference, Vaughn Vernon said trying to understand such questions, and react to the results, is the essence of Domain-Driven Design. Using a Ubiquitous Language to describe a system composed of Bounded Contexts helps to tackle the complexity of distributed systems. Concepts of uncertainty, especially regarding communication between bounded contexts, need to become part of the ubiquitous language.

Vernon, author of Implementing Domain-Driven Design and Reactive Messaging Patterns with the Actor Model, said creating a good context map was vital to a project. Practically speaking, there will always be multiple Bounded Contexts in the core domain of a business, and context maps show the relationships between bounded contexts. When drawing a context map, focus on understanding the team relationships between contexts instead of the technical details, such as using REST or RPC. In Vernon's words, "Who you are integrating with is more important than how you are integrating."

Vernon sees a trend to reactive systems, where reactive behavior exists within, and also extends beyond, a single microservice. This isn't entirely new, and he said Eric Evans was ahead of the industry in advocating eventing patterns. The basic idea is to react to events that happened in the past, and then bring the state into harmony.

With microservices and reactive behavior comes uncertainty, including uncertainty about what order events might be delivered in, and the possibility of events being delivered twice. Vernon cautions that, "Even if you're using a messaging system like Kafka, and you think you're going to consume them in sequential order, you're fooling yourself. If there is any possibility of any message being out of order, you have to plan for all of them being out of order."

"If there is any possibility of any message being out of order, you have to plan for all of them being out of order." - Vaughn Vernon

Vernon believes this uncertainty is difficult to deal with because we have become "addicted" to ideas like blocking calls, expecting a proper ordering of things, and database locking. In reactive systems, those long-held beliefs start to break down. While a developer's instinct may be to create a façade that hides the uncertainty, and allows the code to behave like traditional, non-reactive software, Vernon says exactly the opposite approach should be used.

He summarized his approach to dealing with uncertainty as "Query less; Event more." Events show us what happened at a specific point in time. We don't know the state of the system now, we just know the state when the event occurred, and what changed. How to react to those events, including when they happen out of order, must be a business decision, discussed using the ubiquitous language. He cited the paper by Pat Helland, Life Beyond Distributed Transactions: "In a system that cannot count on distributed transactions, the management of uncertainty must be implemented in the business logic."

Vernon described several scenarios with different forms of uncertainty, and included brief code samples to manage each. However, he emphasized that the code merely showed an implementation of what has to be a business decision. Businesses must embrace a mindset that considers uncertainty, and it must be modeled in the open, with business decision makers, not within software development teams. Don't try to create a façade that allows you to think you aren't in a state of uncertainty. Rather, make your best effort and model the uncertainty.

Editor's Note: An earlier version of this story incorrectly stated that the concept of Domain Events was introduced by Eric Evans in Domain-Driven Design.

Dear Thomas, Eric Evans wrote a lot of interesting wisdom in his book, but I don't think domain events were one of them.I have no idea when they came about, but I guess it must have been when dddd became a thing which we currently know as cqrs.Still liked your article though.Best regards

In his presentation, Vaughn gave credit to Eric for being "far ahead of the industry when he introduced eventing." I assumed, incorrectly, that this referred to the original book. I reviewed my copy, and can't find Domain Events called out explicitly, just in some examples.

Events which are talked here, don't have much to do with the cqrs/event sourcing. In event sourcing, all the state changes must be save as events. In DDD events are information, what have happened inside a bounded context / (micro) service.

“Even if you're using a messaging system like Kafka, and you think you're going to consume them in sequential order, you're fooling yourself. If there is any possibility of any message being out of order, you have to plan for all of them being out of order."

I understood what Mr. Vernon wants to say here. Of course, if we forget to pass a key in a Kafka message we lost the order guarantee per partition. But, in ACID world there are many other aspects that represent the same idea, for example, if we forget to turn on a foreign key constraint, we can cause an inconsistence in our domain, or how to deal with stale data in GUI. After all, we always need to embrace the uncertainty and model thinking on these cases. In a reactive domain events microservices world or not, we need to discuss with domain experts to learn together how to deal with uncertainty.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.