BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Domain-Driven Design and Microservices

Domain-Driven Design and Microservices

Leia em Português

This item in japanese

Bookmarks

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

  • DDD is a superficial concept

    by navr sale,

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

    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?)

  • Examples

    by Sergii Starodubtsev,

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

    No examples of "Interchange Context" in the form of code, or folder structure, just theory.. (?)

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