Eu sempre considerei o Bounded Context (Contexto Delimitado) de um Projeto Orientado a Domínio (Domain-Driven Design – DDD) como uma diretriz para definir os limites dos Microsserviços. Eu estava errado. Esta heurística não só é falha, como também os Contextos Delimitados são exatamente o oposto dos Microsserviços! Para explicar esse ponto de vista, começarei com uma rápida revisão do que são Bounded Contexts; e então discutirei a relação entre Bounded Contexts e Microsserviços.
Esse texto é uma tradução autorizada do artigo escrito por Vladik Khononov. Para acessar a versão original em inglês, clique aqui.
Curso Intensivo em Projeto Orientado a Domínio e Bounded Contexts
Em “Domain-Driven Design: Tackling Complexity in the Heart of Software” (Domain-Driven Design: Atacando as Complexidades no Coração do Software), Eric Evans argumenta que a má colaboração entre especialistas no domínio e equipes de desenvolvimento de software faz com que muitos esforços de desenvolvimento fracassem. O Projeto Orientado a Domínio visa aumentar as taxas de sucesso, fazendo a ponte entre colaboração e comunicação.
Linguagem Ubíqua
Para permitir o compartilhamento fluente de conhecimento, o DDD exige o cultivo de uma linguagem compartilhada, orientada ao domínio do negócio: a Linguagem Ubíqua. Essa linguagem deve se assemelhar ao domínio do negócio, seus termos, entidades e processos. A Linguagem Ubíqua deve ser amplamente usada durante todo o projeto. Toda comunicação deve ser feita na Linguagem Ubíqua, e toda documentação deve ser formulada com ela. Até mesmo o código deve “falar” a Linguagem Ubíqua. A Linguagem Ubíqua se torna o modelo do domínio do negócio implementado no código.
Bounded Contexts
Definir uma Linguagem Ubíqua não é uma tarefa trivial. Como os softwares não lidam bem com ambiguidade, cada termo de Linguagem Ubíqua deve ter um único significado. Infelizmente, não é assim que as linguagens humanas funcionam – as palavras geralmente têm significados diferentes em contextos diferentes. Para superar esse obstáculo, o DDD exige que cada Linguagem Ubíqua tenha um contexto de aplicabilidade estrito e bem definido. Este contexto é chamado de Contexto Delimitado. Ele define um limite, uma fronteira dentro da qual uma Linguagem Ubíqua pode ser usada livremente. Fora disso, os termos da linguagem podem ter significados diferentes.
Exemplos
Esses “significados” podem diferir de várias maneiras. Primeiramente, o mesmo termo pode descrever coisas completamente diferentes. Martin Fowler tem um exemplo sofisticado de tal caso: ele conta que, quando ele trabalhava para uma empresa de eletricidade, a palavra “medidor” tinha significados distintos em diferentes partes da organização. Em um departamento, ele se referia à conexão entre a rede e uma unidade consumidora de energia. Outros entendiam “medidor” como a conexão entre a rede e o cliente ou, é claro, um medidor físico ligado a uma casa para medir o consumo elétrico.
Em segundo lugar, diferentes partes interessadas podem representar a mesma entidade de negócio em diferentes modelos. Por exemplo, uma Campanha de Publicidade é uma entidade complexa com muitas regras e invariantes para os gerentes de campanha; mas para agentes de vendas, uma Campanha de Publicidade é apenas uma estrutura de dados que descreve um subconjunto de seus metadados. Esses são dois modelos diferentes e, portanto, pertencem a dois Bounded Contexts diferentes.
Finalmente, como em Projeto Orientado a Domínio a linguagem é o modelo, e vice-versa, cada Contexto Delimitado define o contexto de aplicabilidade de um modelo específico. Um modelo só é válido em seu Contexto Delimitado.
O que significa tudo isso no contexto dos Microsserviços?
Microsserviços
No contexto de Microsserviços, isso significa algo simples: um Contexto Delimitado é exatamente o oposto de um Microsserviço!
Um Contexto Delimitado define os limites dos maiores serviços possíveis: serviços que não terão modelos conflitantes dentro deles. Se um microsserviço cruzar os limites de um Contexto Delimitado, é provável que o conflito entre dois ou mais modelos abrangidos pelo microsserviço acabarão levando a uma situação toxica. Por outro lado, se você desenhar seu microsserviço como sendo exatamente igual ao Contexto Delimitado, você obterá monolitos. Esses serão “bons” monolitos, já que não haverá modelos conflitantes dentro deles, mas, ainda assim, não será um microsserviço. Entretanto, se você decompor ainda mais o Contexto Delimitado, é bastante provável que encontre os microsserviços desejados. No entanto, nem o Projeto Orientado a Domínio em geral, nem os Bounded Contexts em particular, fornecem orientação sobre como fazê-lo.
Um grande monolito e um pequeno monolito, do ponto de vista do Projeto Orientado a Domínio, são Bounded Contexts perfeitamente válidos, desde que não contenham modelos conflitantes. Portanto, um microsserviço é um Contexto Delimitado, mas não vice-versa. Nem todo Contexto Delimitado é um microsserviço.
… Talvez Subdomínios?
Não.
Alinhar Bounded Contexts a subdomínios de negócio é outra heurística popular para decompor sistemas em microsserviços. No entanto, até mesmo subdomínios podem ser decompostos ainda mais.
Portanto, alinhar Bounded Contexts com subdomínios de negócio também não é uma receita para a decomposição de um sistema em Microsserviços.
O Que Então?
Mas se Bounded Contexts não são Microsserviços, então o que são esses Microsserviços? Esse será o tópico do meu próximo post sobre Microsserviços (leia traduzido aqui).
Autor: Vladik Khononov
Publicado originalmente em vladikk.com
Você também pode segui-lo no twitter: @vladikk
