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.
