Domain-Driven Design: uma introdução para desenvolvedores, artistas, responsáveis ou

degustadores de café com leite - Eriksen Costa

O conceito de agilidade surge de um cenário em que os processos que não estavam diretamente
relacionados ao desenvolvimento de softwares, e eram aplicados de forma burocrática e de
difícil imersão dos interessados no projeto. Porem haviam esforços para a criação de
metodologias de desenvolvimento que trouxessem mais agilidade a forma como o software era
desenvolvido. De forma consequente a esses esforços, surge o desenvolvimento ágil que
pretere a criação de documentação em relação ao desenvolvimento de código.

O foco no código fez com que algumas vezes a idealização do projeto sai-se do interesse final do
cliente, para se tornar centrado no desenvolvimento de software de forma simplória. Em muitos
casos, se aplica o processo ágil para comunicação, mas nem sempre o produto final se utiliza de
estratégias ágeis. Eriksen Costa sumariza: “Pensa-se em usar a comunicação sem o uso técnico
da agilidade”. O principal fator associado a esse desvio de foco do projeto provem da ideia de
que fazer design atrasa a entrega de software. Por mais que se deva ser ágil, isso não significa
que se deva ter pressa no desenvolvimento de software, porém não se pode perder tempo nos
projetos (desperdício de tempo é ruim tanto para desenvolvedores quanto para os clientes da
solução).

A pressa no desenvolvimento gera o que pode ser considerado uma “grande bola de lama”, ou
seja, uma aplicação que “suja” seus desenvolvedores, tanto pela complexidade quanto pelo
acoplamento, dentre outros fatores. Pode se observar também que mesmo em casos em que o
sistema de informação não seja uma “grande bola de lama”, o mesmo não atende aos requisitos
do que deveria ser desenvolvido. Dois fatos incontestáveis sobre a comunicação entre a equipe
de desenvolvimento são os seguintes: Quem entende do domínio nem sempre sabe programar
(Caso contrário, já estaria o fazendo). Quem programa nem sempre sabe do domínio (Porem,
ANOS de experiencia podem atenuar essa situação).

Quando se fala em domínio, deve se deixar claro o que é esse conceito. Domain pode ser visto
como assunto do projeto e/ou área de concentração da empresa. O Core Domain é a parte
dentro do domínio que está diretamente relacionado aos processos desenvolvidos pelas
empresas, ou seja, parte principal do negócio, onde a empresa tem interesse. Model significa
uma abstração dentro do Domain. Como esses conceitos nem sempre parecem ter uma
definição simples, usa-se o design estratégico (divisão de contextos) para viabilizar a projeção de
domain no contexto de software. Ainda sobre o desenvolvimento de software, quando se
trabalha sobre um projeto, todos os termos devem ser claros para que não haja ambiguidade no
desenvolvimento de modelos. Isso se chama linguagem ubíqua. Algumas ferramentas como o
mapa de modelos permitem a visualização de contextos usando uma linguagem parecida com a
de casos de uso.

De forma geral, o DDD, é um framework de design que ajuda a definir nível de acoplamento
entre contextos e escrever código com uma “cara” do domain do problema. As principais
prioridades do DDD são: as conversas, a estrutura de microserviços, e a entrega de software. Os
microserviços não são obrigatórios no DDD, porem o uso de DDD leva a projetar aplicações
usando microserviços. Outro ponto que deve ser destacado é que mesmo com todas essas
diretrizes. O projeto no DDD só pode ser considerado pronto, quando entregue, o que mostra
como esse framework visa a criação de código mais humano e funcional.