BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

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

Bookmarks

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
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.

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

Community comments

  • Domain events

    by Jan Bols,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Are Kafka guarantees valid?

    by Eldon Coutinho,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    “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’m curious about what Kafka guys think about this.

  • Re: Are Kafka guarantees valid?

    by Eldon Coutinho,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

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

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

BT