Afinal, o quê é Domain Driven Design (DDD)? (Parte 1)

Olá! Meu nome é Luís Felipe Arten e este é meu primeiro post aqui no dev.to. Sou aluno de Engenharia de Software e desenvolvedor full-stack. Espero contribuir de alguma forma para a comunidade espalhando conhecimento e discutindo sobre programação, arquitetura de software, padrões de design, etc.

Afinal, o que é não é DDD?

DDD não é sobre arquitetura, metodologia de código, organização de pastas. Alguns devs em começo de carreira podem sentir um pouco de dificuldade em se adaptar, já que muito do que aprendemos no início se refere a código limpo, organização de projeto e arquitetura de software.

O DDD é uma filosofia de desenvolvimento cuja premissa básica é que o Software deve se relacionar diretamente ao problema (Domínio) a que se propõe resolver.

"The heart of software is its ability to solve domain-related problems for its user." - Evans, Eric. Domain Driven Design: Tackling Complexity in the Heart of Software

Sendo assim, Eric Evans a proposta que o DDD traz é que devemos atacar diretamente as regras de negócio, onde coletamos as situações do mundo real e aplicamos lógica de programação para automatizar o processo.

"Tá bem, Arten, mas ainda não está claro o quê é Domínio!"

Ora, por Domínio podemos exemplificar o caso de um profissional especialista em direito tributário. A todo momento os órgãos e instituições competentes alteram as normas, orientações e leis do sistema de tributos. O papel do DDD é buscar entender como essas adptações de entendimento, mudanças de cálculo e demais representações do cotidiano real do profissional tributarista se dariam caso fossem feitas manualmente, para então criar possibilidades de automatização destas tarefas atacando diretamente o problema e sua complexidade.

Portanto, o Domínio é o guia do projeto. O profissional especialista em direito tributário é quem realmente conhece o funcionamento e os processos do negócio. É a figura central e com quem a troca de informações deve ser o ponto focal do time de desenvolvimento.

E aí entra a primeira dificuldade: como envolver um profissional que está habituado a Artigos, Incisos e Anexos no processo de desenvolvimento, onde Entidades, Classes, Métodos, e Casos de Uso são o bê-a-bá? Esbarramos novamente no grande paradoxo universal da linguagem?

A resposta é sim! E para resolver isso, a proposta do DDD é justamente lançar mão de padrões estratégicos e padrões táticos. Resumidamente: os padrões estratégicos permitem que os times de desenvolvimento de software mapeiem, entendam os padrões e regras de negócio; enquanto os padrões táticos são aqueles aplicados diretamente no código do projeto.

fonte: Domain-driven design in functional programming

Dentre os padrões que Evans propõe, há um que chamamos de Linguagem Ubíqua. Nela utilizamos conceitos do mundo real para que mesmo quem nunca escreveu uma linha de código possa entender quais são as Entidades, as Classes e seus atributos de um projeto.

No caso do nosso especialista em tributos, provavelmente iremos tratar de Regime de Impostos, Alíquotas, Natureza Jurídica, fatores de exclusão/isenção, fórmulas de cálculo, etc. E é com base nisto que iremos modelar nossas representações dentro do software, mantendo coesão e coerência com o mundo real e utilizando a linguagem por todo o código, sem adaptações tempestivas, introdução de conceitos técnicos ou ferramentais da programação, que por sua vez escapariam ao Domínio e, consequentemente, aumentariam a complexidade e entropia dentro do sistema.

E aí, ficou um pouco mais claro? Espero que sim!

Na parte 2 vamos avançar mais sobre como o DDD pode ser isolado da Arquitetura, evitando que o código e as ferramentas utilizadas invadam o nosso Domínio. Muito obrigado pela leitura. Fique a vontade para deixar o seu comentário abaixo. Um grande abraço e até a próxima!

Fontes:

Domain-Driven Design: Atacando as complexidades no coração do software

DDD - Domain-Driven Design com .NET

DDD não é sobre arquitetura - O que é Domain-Driven Design | Dias de Dev