Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Vaughn Vernon Uses Reactive DDD to Model Uncertainty in Microservices

Vaughn Vernon Uses Reactive DDD to Model Uncertainty in Microservices

Leia em Português

This item in japanese

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.

Rate this Article