No QCon Londres 2016, Eric Evans, autor do livro Domain Driven Design, Tackling Complexity at the Heart of Software, defendeu o uso do conceito de DDD para reduzir a complexidade de linguagens ubíquas em ambientes voltados a microservices.
Linguagens ubíquas entre equipes apresentam questões particulares no gerenciamento de um ambiente voltado para microservices. As equipes desenvolvem suas próprias linguagens ubíquas e codificam com o significado adquirido no escopo dos próprios domínios. No entanto, os conceitos dessas linguagens ubíquas não mantêm a consistência fora do contexto da equipe. O termo "cliente" para uma equipe pode ter outro significado para outra, gerando complexidade desnecessária. Cada linguagem evolui dentro do escopo da equipe, o que resulta em diferentes definições de conceitos entre equipes.
Evans fala sobre os erros e mal-entendidos em requisitos cometidos no código, resultando em erros e código de baixa qualidade. Embora isso aconteça de vez em quando, o pior cenário ocorre quando tais erros respingam em outros microservices independentes. Evans destaca o que chama de "grande bola de lama", em que questões sobre microservices irão se estender através do ambiente.
Evans apresenta três ferramentas de DDD que podem auxiliar no gerenciamento de um ambiente microservices: context maps, anti-corruption layer (ACL) e interchange context. O context map representa os caminhos de comunicação entre os microservices e sugere interações apropriadas entre as equipes de microservices. Uma vez que essa análise está madura, a equipe pode escolher ser dependente de uma linguagem de domínio de outra equipe, na qual um ACL pode fazer sentido.
Uma responsabilidade da ACL é traduzir conceitos externos para um modelo interno com a intenção de fornecer baixo acoplamento entre os domínios. Em uma situação quando duas equipes precisam mais do que uma relação de parceria, o interchange context é mais indicado, pois fornece uma camada para ambas as equipes discutirem o significado das palavras e traduzirem as linguagens dos microservices.
A migração de código de um sistema monolítico para um sistema baseado em microservices desloca a complexidade contextual do código para o espaço entre os serviços. Agora, a interação entre os microservices possui a mesma lógica que existia em um código fácil de ler e depurar. Esse novo contexto deve ser gerenciado, ou todo o sistema pode transformar-se no que Evans chama de "grande bola de lama".
Evans sugere projetar cada microservice como um contexto limitado do DDD. Isso fornecerá um limite lógico dos microservices dentro do sistema, tanto em relação à funcionalidade, quanto para a linguagem ubíqua. Cada equipe independente se torna responsável por uma parte definida do sistema. Como resultado, o código produzido pela equipe é mais fácil de entender e manter.