BT

Domain-Driven Design and Microservices

| by Mikael Zandin Follow 0 Followers on Apr 22, 2016. Estimated reading time: 2 minutes |

At the QCon conference in London, 2016, Eric Evans, author of Domain Driven Design, Tackling Complexity at the Heart of Software, argues that using domain-driven design (DDD) concepts can mitigate against ubiquitous language complexity in microservice environments.

Discrete ubiquitous languages between teams present particular issues with regard to managing a microservice environment. Teams will develop their own ubiquitous languages and codify their meaning within the scope of their domains. However, the concepts of these ubiquitous languages do not maintain consistency beyond the context of that team. One team’s definition for “customer” may significantly differ from other teams’ definition, yielding unnecessary complexity. Also, each language evolves within the scope of its team, almost guaranteeing that disparate definitions will exist at one time or another.  

Evans speaks about teams making coding mistakes and misunderstanding requirements, resulting in errors and bad code. While this happens on occasion, the worst-case scenario occurs when these mistakes bleed over into otherwise unrelated microservices. Evans discriminates between what he calls “a small ball of mud”, where problems are contained in one microservice, and “a big ball of mud”, where the issues in one microservice will extend throughout the environment.

Evans presents three DDD tools that can aid in the management of a microservice environment: the context map, the anti-corruption layer (ACL) and the interchange context. The context map represents the communications paths between microservices and suggests appropriate interactions between microservice teams. Once this analysis is mature, a team can choose to be dependent on the domain language of a different team, in which case an ACL may make sense. An ACL’s responsibility is to translate external concepts to an internal model with the intent of providing loose coupling between domains. In the situation where two teams require more of a partnership relationship, the interchange context might make more sense. The interchange context is more robust than the ACL, providing a layer where both teams discuss the meaning of their words and translate the languages of the microservices back and forth.

Migrating code from a monolith to a system of microservices displaces contextual complexity from the code to the space between the services. The interaction between microservices now contains the logic that used to exist in easily readable and debuggable code. This new context must be managed, or the whole system can devolve into what Evans calls a “large ball of mud”.

Design each microservice as a DDD-bounded context, Evans suggests. This will provide a logical boundary for microservices inside a system, both regarding functionality and ubiquitous language. Each independent team becomes responsible for a logically defined slice of the system. As a result, the code the team produces is more easily understood and maintainable.

 

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

DDD is a superficial concept by navr sale

I do not see the difference between <<tier>> and <<bounded context>> concepts. While Bounded Context is flexible, so is the Tier concept. Tier concept comes from Layers and Tiers architectural pattern.
Using Tiers and Layers concepts, we can replace Bounded Context, Context Map etc. concepts entirely. Tiers can span Layers, but Layers can span Tiers as well. Thus, we can use Tier concept to depict Context Map of the entire enterprise architecture. And we can have more detailed layers and tiers inside these Tiers (Contexts), as we move from enterprise architecture toward enterprise segments architectures or individual macro designs.
In the solution space, there is also a concept of <<subsystem>> and <<system>>, which are well defined in UML, to distinguish between specification and realization phases. We can reuse either of these and many UML profiles already exist.

Thus, I see no reason for introduction of any of DDD concepts, which are in my opinion superficial. Yes, there were use case driven designs, but there were data driven designs as well. As 3-tier architectures were introduced, these data driven designs were renamed to business view data driven designs, i.e. there is nothing new that DDD introduces (remember good old OOA/OOD from the early 90s?)

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

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