As 7 dimensões do Domain Driven Design

Domain Driven Design (DDD) é uma abordagem de design de software que tem como objetivo principal criar sistemas flexíveis e adaptáveis, alinhados com o domínio do negócio. Desenvolvido por Eric Evans e apresentado em seu livro “Domain-Driven Design: Tackling Complexity in the Heart of Software“, o DDD oferece um conjunto de práticas e conceitos que visam simplificar o processo de desenvolvimento de software, tornando-o mais eficiente e orientado ao negócio. Por conta disso, construimos o artigo as 7 dimensões do Domain Driven Design.

Neste artigo, exploraremos as diferentes dimensões do Domain Driven Design, desde os conceitos essenciais, passando pelos elementos populares até as estruturas mais avançadas. Discutiremos como a linguagem ubíqua, os blocos de construção, os contextos e outros conceitos fundamentais se relacionam e contribuem para a criação de software de alta qualidade. Além disso, abordaremos as práticas avançadas, como o design flexível e as estruturas em larga escala, que são essenciais para lidar com a complexidade de sistemas empresariais modernos.

As grandes grupos do DDD

Domain Driven Design é um conjunto de práticas voltadas para a construção de softwares flexíveis. Ela tem características bastante técnicas (Entidades, ValueObjects), estratégicas (domínios, mapas de contexto), e outras visões ligadas ao design, comunicação, padrões de análise etc. Com isso temos 7 dimensões que dividi em 3 grandes grupos: essenciais, populares e avançados.

O essencial trata da linguagem ubíqua (onipresente ou universal) e o desenvolvimento orientado à modelagem. Na minha visão esses pontos deveriam ser o core do DDD e não o domínio propriamente dito, mas a sigla DDD vende mais. Esses estão em verde, no centro do diagrama.

Assim, chamei de popular os itens em azul no diagrama que infelizmente muita gente só conhece esses. Alguns não conhecem nem esses e acreditam que DDD é só a divisão de pastas dentro do VSCode. Triste! Mas esses elementos são diretamente ligados à técnica, seja programando ou separando estruturas. O item Destillation (destilação) coloquei junto dos azuis, mas em outra cor, isso por que ele é avançado, mas o conceito de domínio acaba sendo popularmente conhecido.

O último grupo, o avançado, lida com padrões para flexibilização das estruturas de código, padrões de domínio e padrões de análise para larga escala. É incomum ver pessoas falarem sobre o Domain Driven Design sob esse prisma.

1 – O essencial

Pois bem, o essencial é a fundação. Então, para mim não há DDD se esses elementos não estiverem presentes. Então, entenda, de nada adianta ter um conjunto de pastas que falam sobre o domínio se o código não é fruto de um profundo alinhamento entre a TI e o negócio. Certa vez Eric Evans – autor do livro – foi questionado sobre o que ele mudaria no seu livro azul escrito em 2003. Ele respondeu que daria um foco maior na linguagem ubíqua.

Pois bem, na minha visão o livro se chama Domain Driven Design (DDD) por que formou uma sigla vendável, seguindo o bonde do TDD publicado um ano antes. Acho que “orientado ao modelo” faz mais sentido, sendo o modelo apenas uma expressão da linguagem que conecta negócio e TI.

Portanto, todas as demais dimensões que vou comentar nesse artigo se conectam diretamente a essa dobradinha de Linguagem ubiqua e design orientado ao modelo.

2 – O popular

Chamo de popular as dimensões mais conhecidas: Blocos de Construção, Contexto e um pouco da destilação por conta dos domínios: Mas só por isso.

Os blocos de construção são os mais conhecidos dos mais conhecidos. Essa parte tem uma visão fortemente calcada na técnica, definindo um conjunto de padrões de codificação relevantes para que as premissas de alto nível do DDD sejam alcançadas. Mas, não é alto pragmático. Quero dizer: se você desenvolver um código, parte dele ou até um módulo inteiro, sem usar esse padrão, ainda assim pode-se dizer que o DDD está presente. Para mim o ponto relevante é quanto se trabalha com as estruturas avançadas junto da destilação.

O Contexto e a Destilação

A parte do contexto também é muito conhecida. Nela as estruturas de processo são organizadas de modo que seja possível colocar blocos de construção. Essa visão é bastante técnica mas que carrega características estratégicas. Além disso ela é muito valiosa como ferramenta de comunicação com o cliente final pela linguagem que produz.

Sobre a destilação, vou explicar apenas a parte que, ao meu ver, pode ser considerada popular. As demais explicarei no avançado. Bom, destilar é tornar algo puro. Algo que se parece com otimizar ou refatorar, mas que pode trazer mudanças significativas para o sistema. Nessa dimensão temos o conceito de domínio, que é uma grande área de conhecimento do negócio que o software precisa ficar atento. Vale destacar que o Contexto e o Domínio são dimensões diferentes, mas eles podem se sobrepor, como uma planta baixa que é sobreposta de outras plantas em papel manteiga.

3 – O avançado

As estruturas avançadas do DDD estão próximas da estratégia e de padrões abrangentes que norteiam a construção do software. Como comentei anteirormente, a dimensão Destilação tem características avançadas e populares ao mesmo tempo. Eric considera que não apenas existam os domínios, mas que existam tipos e relações deles nos domínios, dando possibilidades específicas.

Outra dimensão é a do Design Flexível. Isso é o que está por trás especialmente dos tijolos de construção. Por exemplo: porque é tão importante que uma entidade esteja sempre coesa e que nunca seja possível ter dados inválidos em nenhum momento? Talvez o conceito de classes autônomas o tenha motivado a pensar desse modo nas classes concretas. Essa dimensão apoia a construção de sistemas realmente grandes e relevantes.

Boas práticas de design para projetos de larga escala

Por fim, a dimensão mais avançada, ao meu ver, é a de estruturas de larga escala. Assim, ela trás à tona conceitos ligados à padrões de análise e não exatamente padrões técnicos. Um padrão muito relevante é o que o autor chama de ordem de evolução. Pense bem, os requisitos de um software vão evoluindo e isso precisa ser estruturado de modo que o design cresça sempre estruturado.

Referências para as 7 dimensões

Para chegar até esse artigo construí uma série de outros. Veja a seguir todos os 25 artigos que escrevi acerca desse tema.

1 – Ubiquitous Language (Linguagem onipresente) e

2 – Model Driven Design (Desenvolvimento orientada ao modelo)

Não há nenhuma referencia diretamente ligada a esses temas, mas eles estão espalhados por todos os artigos, de certa maneira.

3 – Building Blocks (Blocos de Construção)

• Notification Pattern
• Variantes e Invariantes
• Estrutura de camadas
• Mediator Pattern
• Domain Service
• Validation Pattern
• Specification Pattern
• Factory
• Domain Driven Design tático

4 – Context (Contexto)

• Bounded Contexts livres
• Bounded Contexts: Upstream-Downstream
• Bounded Contexts de dependência mútua
• Modelando o Context map do zero
• Criando Context maps DDD com o VS Code
• Desvendando o Context Map

5 – Destillation (Destilação)

• Domínio destilado
• Domain Driven Design estratégico

6 – Flexible Design (Design Flexível)

• System Design Flexível
• Fechamento de Operações
• Classes autônomas
• Contornos Conceituais
• Afirmações
• Operações isentas de efeitos colaterais
• Interfaces reveladoras de intenções

7 – Large Scale Structure (Estrutura em larga escala)

• Estrutura em Larga Escala

Conclusão de as 7 dimensões do Domain Driven Design

Por fim, nossa análise das diferentes dimensões do Domain Driven Design (DDD), podemos ver como cada uma desempenha um papel importante na criação de software flexível e orientado ao domínio. Então, começando pelo essencial, a linguagem ubíqua e o design orientado ao modelo formam a base sólida sobre a qual todo o DDD é construído, garantindo uma comunicação clara entre todas as partes envolvidas no projeto. Em seguida, as dimensões mais populares, como os blocos de construção e os contextos, fornecem as ferramentas técnicas necessárias para implementar o DDD na prática, garantindo que o código seja robusto e fácil de manter.

Então, as dimensões avançadas, como a destilação e o design flexível, elevam o DDD a um nível superior, permitindo a criação de sistemas complexos e escaláveis (estruturas de larga escala) que podem evoluir com o tempo. Assim, juntas, essas dimensões formam um quadro abrangente que orienta o desenvolvimento de software de alta qualidade, alinhado com as necessidades reais do negócio e capaz de se adaptar às mudanças do mercado. Com isso, espero que com esse artigo você aprenda as 7 dimensões do Domain Driven Design.