BT

Your opinion matters! Please fill in the InfoQ Survey!

Vaughn Vernon Uses Reactive DDD to Model Uncertainty in Microservices

| by Thomas Betts Follow 5 Followers on Oct 09, 2017. Estimated reading time: 3 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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

Adoption Stage
Style

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

Domain events by Jan Bols

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

Re: Domain events by Thomas Betts

Hi Jan,

Thanks for the feedback.

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.

I've updated the article and cited the correction.

Thanks,
Thomas

Re: Domain events by Chris Hartley

It's unclear where they originated, but Martin Fowler talks about writing about them mid 2000.

See martinfowler.com/eaaDev/DomainEvent.html

Re: Domain events by Pasi Taive

Eric has talked abouts events many times.
www.youtube.com/watch?v=lE6Hxz4yomA "What I've learned about DDD since the book"

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.

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

4 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT