Quando usar e quando não usar DDD?

Apesar de muitas pessoas afirmarem utilizar DDD apenas por possuir uma arquitetura em camadas, isto não significa que realmente estejam usando o DDD. Existem algumas interpretações como DDD-Lite que seria uma aplicação utilizando alguns conceitos encontrados no DDD porém ignorando muitos outros.

Para saber se você deve ou não implementar o DDD no seu projeto, disponibilizo abaixo um DDD Score Card extraído do livro Implementing Domain Driven Design.

Se no final o somatório dos pontos for igual ou maior que 7 considere seriamente em implementar o DDD em seu projeto.

Critério 1

• Pontuação: 0 pontos
• Seu contexto: Se sua aplicação for completamente centrada em dados e se qualificar verdadeiramente para uma solução CRUD pura, em que cada operação é basicamente uma consulta simples de banco de dados para criar, ler, atualizar ou excluir, você não precisa do DDD. Sua equipe só precisa colocar um rosto bonito em um editor de tabelas de banco de dados. Em outras palavras, se você puder confiar no fato de que os usuários irão inserir os dados diretamente em uma tabela, atualizá-los e, às vezes, excluí-los, você nem mesmo precisará de uma interface do usuário. Isso não é realista, mas é conceitualmente relevante. Se pudesse usar uma ferramenta simples de desenvolvimento de banco de dados para criar uma solução, você não desperdiçaria o tempo e dinheiro de sua empresa no DDD.
• Análise: Isso parece óbvio, mas normalmente não é fácil determinar simples versus complexo. Não é como se todas as aplicações que não são CRUD puras merecem o tempo e o esforço do uso do DDD. Assim, talvez possamos sugerir outros indicadores para nos ajudar a traçar uma linha entre o que é complexo e o que não é …

Critério 2

• Pontuação: 1 ponto
• Seu contexto: Se seu sistema exigir apenas 30 ou menos operações de negócio, ele provavelmente é bem simples. Isso significaria que a aplicação não teria um total de mais de 30 histórias de usuário ou fluxos de caso de uso, com cada um desses fluxos tendo apenas uma lógica mínima de negócio. Se você puder desenvolver rápida e facilmente esse tipo de aplicação e não se importar com a falta de poder e controle em relação à complexidade e alteração, o sistema provavelmente não precisará usar o DDD.1
• Análise: Para ser claro, estou falando de 25 a 30 únicos métodos de negócio, não de 25 a 30 interfaces de serviço completas, cada uma com vários métodos. O último pode ser complexo.

Critério 3

• Pontuação: 2 pontos
• Seu contexto: Assim, digamos que, em algum lugar no intervalo entre 30 e 40 histórias de usuário ou fluxos de caso de uso, a complexidade poderia ser pior. Seu sistema pode estar entrando no território do DDD.
• Análise: O risco é do comprador: Bem frequentemente a complexidade não é reconhecida rapidamente. Nós, desenvolvedores de software, somos realmente muito bons para subestimar a complexidade e o nível de esforços. Só porque talvez queiramos codificar uma aplicação em N camadas com diversos Patterns não significa que devemos. No longo prazo, essas aplicações poderiam prejudicar mais do que ajudar.

Critério 4

• Pontuação: 3 pontos
• Seu contexto: Mesmo que a aplicação não seja complexa agora, a complexidade dela aumentará? Você só pode saber isso ao certo depois que os usuários reais começam a trabalhar com ela, mas há um passo na coluna "Pensamentos de suporte" que pode ajudar a revelar a situação real. Tenha cuidado aqui. Se houver absolutamente qualquer indício de que a aplicação tem complexidade mesmo moderada - este é um bom momento para ser paranoico, isso pode ser uma indicação suficiente de que ela na verdade será mais do que moderadamente complexa. Incline-se em direção ao DDD.
• Análise: Aqui vale a pena analisar os cenários de uso mais complexos com especialistas em domínio e ver aonde eles levam.Os especialistas em domínio: #1 Já estão solicitando recursos mais complexos? Se sim, isso provavelmente é uma indicação de que a aplicação já é ou em breve se tornará excessivamente complexa para usar uma abordagem CRUD.#2 Estão entediados com os recursos ao ponto em que dificilmente vale a pena discuti-los? Provavelmente não é complexa.

Critério 5

• Pontuação: 4 pontos
• Seu contexto: Os recursos da aplicação serão alterados com frequência ao longo de alguns anos, e você não pode antecipar que as alterações serão simples.
• Análise: O DDD pode ajudá-lo a gerenciar a complexidade da refatoração de seu modelo ao longo do tempo.

Critério 6 e último

• Pontos: 5 pontos
• Seu contexto: Você não entende o Domínio porque ele é novo. Na medida em que você e sua equipe sabem, ninguém fez isso antes. Isso provavelmente significa que ele é complexo ou, pelo menos, merece a devida diligência com análise analítica para determinar o nível de complexidade.
• Análise: Você precisará trabalhar com Domain Experts e testar os modelos para fazer a coisa certa. Você certamente também pontuou em um ou mais dos critérios anteriores, portanto, use o DDD.

Ao finalizar este exercício você terá mais clareza para determinar se o DDD é viável ou não para o seu projeto. Lembre-se de tomar as decisões com foco na simplicidade, entrega e manutenção. Muitas vezes sofremos da vontade incontrolável de implementar todos os conceitos de nossos estudos, porém estamos colocando em risco o dinheiro da empresa e nossa própria carreira.