Design: Desfazendo Mal-entendidos - DDD

Olá!

Este é mais um post da sessão Design, dentro da série Desfazendo Mal-entendidos e, a exemplo do post CQRS - Desfazendo mal-entendidos, vamos falar de falhas de interpretação comuns quando o assunto é DDD.

Vou começar com duas afirmações, que vou defender ao longo do post:

1. DDD não é sobre código
2. DDD não é um padrão arquitetural

Afirmação 1: DDD não é sobre código

Esta é, talvez, a maior falha de interpretação em relação a DDD. Muitos acreditam que, ao utilizar os patterns do DDD, como Agregados, Entidades, Repositórios etc., está se praticando DDD.

Bom, nada mais distante da verdade.

DDD não é uma maneira de escrever código. DDD é uma prática de gestão do conhecimento.

Agora você pode estar com uma pulga atrás da orelha, se perguntando: gestão do conhecimento?

Soa estranho. Não? Mas é a mais pura verdade!

Já parou pra pensar no porque de, no famoso livro azul do Eric Evans, a Linguagem Ubíqua ser o primeiro assunto abordado? É porque é o conceito mais importante de DDD! Todos os demais conceitos derivam de sua correta compreensão. Ou seja, sem ela, você estará, apenas, aplicando patterns em sua aplicação, e isso não terá nada, nada!, de DDD.

Comecemos, então, por ela.

Linguagem Ubíqua (ou Universal)

A Linguagem Ubíqua é o coração do DDD, e vamos entender o motivo.

A comunicação é um problema frequente na execução de projetos. Quantas histórias não conhecemos sobre entregas que falharam porque faltava clareza entre o cliente (aqui cliente pode significar tanto o cliente final, quanto um PO, PM ou qualquer pessoa que demande o desenvolvimento de software) e o time técnico, o que resultou em uma funcionalidade que não atendia à demanda original? Além disso, quantas vezes o próprio código não expressava de forma precisa sua intenção e o papel que cumpria em um dado processo de negócio?

Este é o ponto: quanto menos comum for a linguagem estabelecida no trato com domínio, a partir do jargão do negócio, maior será a influência do jargão técnico sobre o código, e menor será a clareza sobre qual papel em um dado processo de negócio ele desempenha.

A Linguagem Ubíqua tem, portanto, a função de reduzir ao máximo o ruído na comunicação, tornando, por consequência, o domínio mais claro e o código mais expressivo, demonstrando como este código se enquadra no processo de negócio com o qual está envolvido.

Percebe agora como não faz sentido apenas implementar patterns?

Implementar patterns não é o mesmo que praticar DDD. Praticar DDD é formalizar uma linguagem em um dado domínio, que fará referência ao processo de negócio que visa atender, levando essas referências ao código, tornando o conhecimento algo coeso e bem distribuído entre os chamados "especialistas de domínio", aqueles que conhecem bem o negócio (e de quem se esperam as demandas de desenvolvimento), e o time técnico, que fará as entregas de software.

Contextos Delimitados

Certa vez, quando perguntado sobre como resumiria DDD em uma frase, Vaughn Vernon, autor do famoso livro vermelho, respondeu: "linguagem ubíqua e contextos delimitados".

E o quão importantes são os contextos delimitados na prática do DDD?
São tão importantes quanto a Linguagem Ubíqua, uma vez que, como o próprio nome sugere, delimita o escopo de uma implementação, replicando o escopo do processo de negócio que visa atender.

Nota: quando Evans escreveu o livro azul, em 2003, os chamados "produtos digitais" ainda eram um conceito a ser explorado e, à mesma época, o mais comum eram os chamados "sistemas corporativos", que visam automatizar processos de áreas de negócio dentro de uma organização. Portanto, fazendo uma analogia simplista, podemos relacionar cada processo de negócio a uma funcionalidade autônoma de um produto digital, como um carrinho de compras, ou o processo de finalização de um pedido em uma loja virtual.

E por que Contextos Delimitados são importantes? O grande segredo aqui é isolamento. A ideia é evitar que funcionalidades complementares se misturem, tornando seu relacionamento uma questão de integração, em vez de permitir que se transformem no que alguns chamam de "código macarrônico" ou "a grande bola de lama".

Existe um conceito em DDD chamado Core Domain (ou Domínio Central, em tradução livre). Este é o domínio mais importante do problema a ser solucionado. Dito de outra forma, é a principal funcionalidade que o software deve oferecer.
A questão é que, normalmente, existe a necessidade dessa funcionalidade ser acompanhada de outras, que são chamadas de Subdomínios de Suporte, quando são uma extensão do negócio (por exemplo, o cadastro de clientes em um sistema de Internet Banking), ou de Subdomínios Genéricos, quando são, grosso modo, uma extensão técnica/de infraestrutura (como, por exemplo, o sistema de autenticação, que não representa, por si mesmo, um processo de negócio, mesmo sendo necessário à solução).

Pois bem. Agora imagine se todas essas funcionalidades forem implementadas juntas, sem clareza sobre seu relacionamento e, principalmente, sobre qual o seu escopo. Seria uma bagunça. Não? Pois é! Ou seja, o objetivo dos Contextos Delimitados é definir escopos, dando espaço para que o relacionamento entre os mesmos seja claro. Neste ponto, um outro conceito entra em ação, o Mapa de Contextos, mas ele está fora do escopo deste post (embora ilustre sua capa). Resumidamente, o Mapa de Contextos é um diagrama que demonstra a distribuição dos contextos delimitados, seus relacionamentos, e principais componentes (normalmente agregados).

Conclusão

Espero que, a esta altura, esteja claro o que quero dizer com gestão de conhecimento. A principal ideia do DDD é tornar o conhecimento o mais coeso e organizado possível tanto dentro (código) quanto fora (comunicação) do software implementado.

Portanto, se você deseja, de fato, praticar DDD, preste muita atenção a estes conceitos, e aos demais que extrapolam o código, descritos na literatura já mencionada.

Afirmação 2: DDD não é um padrão arquitetural

É muito comum que se confunda DDD com um padrão arquitetural. Afinal de contas, ele te oferece padrões, trata de camadas no livro azul (aplicação, domínio e infraestrutura), e isso representa um padrão arquitetural por definição. Certo?

Aqui vai um sonoro "errado"!

No livro azul, Evans se utiliza, sim, de um pattern arquitetural, mas não faz dele parte do DDD. É, simplesmente, o padrão mais comum à época da escrita do livro, conhecido como "3 Tier" ou "3 Camadas". Como dito na nota acima, o livro foi escrito pensando em aplicações corporativas e, naquele momento, este era o padrão arquitetural mais comum.

Isso significa, portanto, que DDD pode ser aplicado sobre qualquer padrão ou estilo arquitetural, sem qualquer prejuízo de sua prática, uma vez que, respeitados a Linguagem Ubíqua, os Contextos Delimitados, e os demais princípios não expostos neste post, ela estará salvaguardada.

Conclusão

DDD não tem vínculo direto com qualquer padrão ou estilo arquitetural, podendo ser utilizado com qualquer estilo ou padrão como, por exemplo, um monolito com CQRS, ou Microsserviços com Ports and Adapters

Nota: Apesar de não haver vínculo direto entre DDD e estilos arquiteturais, recomendo fortemente a sua prática quando Microsserviços for o estilo arquitetural de escolha.
DDD é uma prática muito útil para, a partir do conhecimento por ele gerado e gerido, permitir uma antevisão mais precisa sobre os diferentes serviços que podem atender ao domínio, além de tornar mais claro como aplicar a Lei de Conway (veja em Considerações Finais) a favor dos times de desenvolvimento, a partir da compreensão da distribuição dos domínios.

Considerações finais

A Lei de Conway, mencionada acima e cunhada por Melvin E. Conway em 1967, nos diz que o design de um software sempre reproduzirá a estrutura de comunicação da organização.

A partir desta ideia, a Linguagem Ubíqua e os Contextos Delimitados tem sua importância mais evidenciada.
Isso porque ajudam não apenas a escrever software mais conciso e expressivo, como também ajuda a própria organização a ter uma compreensão melhor dos seus processos de negócio e sobre como distribuir seus times de desenvolvimento quando necessário. Pois é, de novo: gestão do conhecimento!

É muito comum a priorização do código em detrimento de princípios e conceitos. Entendo este como um grande erro porque, afinal, o código tem grandes chances de se tornar confuso, demasiadamente complexo e, principalmente, dificil de manter. Sem dizer que gera um aumento gradativo na dificuldade (tempo e custo) de se implementar novas funcionalidades e, consequentemente, aumenta o estresse ao lidar com ele –
sem dizer que passa a prejudicar o negócio.

Minha recomendação final é a seguinte: nunca, nunca!, parta do código ao se envolver com um padrão ou técnica. Entendo o ímpeto de desenvolvedores a chegar "aos finalmentes", afinal também sou desenvolvedor. Mas, falando por experiência, código deveria ser, sempre, a última preocupação.
Não à toa Eric Evans define o código como um produto da prática do DDD, e não como um de seus componentes.

Apêndice – 20 Anos do Livro Azul

Neste ano, mais precisamente em 20 de agosto, completar-se-ão 20 anos da publicação do livro azul, por Eric Evans.

Dentre as diversas práticas que tive a oportunidade de aprender em relação a desenvolvimento de software, DDD é minha predileta, por ter se proposto a romper a barreira entre negócio e engenharia.

A partir de então, ficou evidente a vantagem trazida pela aproximação de ambos para o sucesso de projetos de software, e a prática se tornou parte importante de organizações bem configuradas.

Fica registrado aqui meu apreço por este livro e, principalmente, pela capacidade de Evans de observar esses dois contextos e, tão bem, integrá-los.

Recomendo fortemente a leitura!

Gostou? Me deixe saber pelos indicadores. Tem dúvidas ou sugestões? Deixe um comentário ou me procure pelas redes sociais.

Até a próxima!