Em DDD, delimitar contextos não é atividade simples. A razão para isso é que as organizações que vão usar os sistemas não tem estruturas simples e, geralmente, há uma relação forte entre a estrutura organizacional e os contextos delimitados.

Conway ensina que a estrutura de comunicação da organização que está desenvolvendo um sistema determina a estrutura desse sistema. Transportando a ideia para DDD, por estrutura do sistema podemos entender os contextos delimitados.

A sutileza da lei de Conway, muitas vezes não percebida, é que ela não se aplica apenas a software house que está escrevendo o código. Mas, também, principalmente, inclui a empresa onde trabalham os especialistas de domínio e que está servindo de referência para o desenvolvimento do sistema.

Vaughn Vernon, DDD e Conway

Vaughn Vernon, uma das maiores autoridades em DDD no mundo, e uma de nossas referências, em conversa recente com nosso time destacou a relevância da lei de Conway e, nós, concordamos com ele.

Quando contextos não estão bem delimitados no software, há acoplamento que facilita o surgimento de dívidas técnicas, aumentando os custos de desenvolvimento, mas, sobretudo de evolução. O problema é que este acoplamento é difícil de superar quando ele existe, de fato, na forma de operar da organização.

Um dos “sintomas” de mudança de contexto é a mudança da linguagem onipresente. Ou seja, quando palavras-chave diferentes passam a ser utilizadas para descrever um conceito já descoberto, ou quando uma palavra já associada a um conceito passa a ser utilizada para descrever um conceito novo. Daí, inferimos que se em nosso mapeamento identificamos dois ou mais contextos, mas, para todos eles temos um único especialista de domínio, há algo errado. 

As diferenças na linguagem onipresente são marcantes no “centro” de cada contexto delimitado. Entretanto, elas ficam obscuras principalmente nas “bordas”. Aliás, é nas bordas que fica difícil determinar quem é o especialista de domínio a consultar.

O fato é que, não raro, as empresas tem atividades certas executadas em departamentos ou setores errados. Quando isso é levado para DDD e é reproduzido no modelo, as consequências são ampliadas.

Na prática, para identificar “vazamentos” nos contextos, oriundos de falhas do processo organizacional, é essencial orientar o processo de descoberta não a formação simples dos glossários de termos, mas ao mapeamento dos principais processos e atividades de negócio. Quando, no mapeamento de um processo, vemos “saltos” frequentes de um departamento para outro, inferimos o acoplamento e problemas de delimitação.

Já afirmamos que, em uma empresa, há sempre pelo menos quatro versões de como as “coisas funcionam”.

Para sermos efetivos, precisamos nos concentrar no dia a dia, nas atividades práticas, e não em descrições ideais. Por isso, recomendamos que o “fio condutor” para a descoberta ocorra através de protótipos de interface e não de documentos escritos.

De qualquer forma, é importante que entendamos que a busca pela delimitação adequada dos contextos implica na externalização da estrutura organizacional e, invariavelmente, nas estruturas de poder das empresas que estamos atendendo. Por isso, é essencial que quem esteja conduzindo a descoberta tenha sensibilidade e soft skills.

Sumarizando, contextos bem delimitados só são possíveis em organizações com estruturas bem definidas. Por isso, o projeto do software deveria ser feito depois da revisão da arquitetura corporativa. 

Contextos bem delimitados implicam em especialistas de domínio distintos para cada contexto e no suporte processos de negócio desacoplados, ou seja, sem “saltos”. O “teste objetivo” da qualidade da delimitação dos contextos começa com a verificação destas duas condições.