Quando eu devo usar DDD?

Em 2003, Eric Evans escreveu um livro chamado Domain Driven Design, que explica como construir software de alta qualidade. Eric se baseia na ideia de que se utilizamos o domínio para guiar o design da nossa aplicação, o resultado é um software flexível, de qualidade e com um fácil nível de compreensão, ajudando na manutenção e extensão da solução implementada.

Um fato muito conhecido é: não é fácil implementar DDD corretamente. A complexidade se deve ao fato de que precisamos mergulhar no negócio, nos apossar de práticas de programação e especialmente de orientação a objetos, conhecer padrões de projeto que serão úteis e, o mais importante, manter a simplicidade da solução.

Quem já estudou DDD sabe que o conceito não é simples, afinal, Eric precisou de quase 600 páginas para explicá-lo e outros autores até apostaram em literaturas mais condensadas e resumidas para ajudar aquelas mais ansiosas que não leram o livro inteiro.

Apesar de todos os benefícios, será que deveríamos aplicar os conceitos de DDD em todas as aplicações? Esses resultados vêm com um custo e às vezes não vale a pena pagá-lo.

O que levar em consideração

• Tamanho — Nem toda a arquitetura é de microsserviços com Bounded Context bem definido. Se esse é o caso da sua aplicação, aplicar DDD vai te ajudar a definir e segregar os domínios dentro do mesmo codebase.
• Complexidade — Se o problema que sua aplicação está resolvendo é complexo, provavelmente você irá se beneficiar do DDD para que o entendimento do código não seja prejudicado.
• Indefinições — Um negócio novo, por exemplo, tem muitas indefinições de como o sistema irá se comportar, afinal o próprio produto ainda tem suas regras em desenvolvimento. Quando esse é o caso, aplicar DDD facilita na flexibilidade de refatorar o seu modelo e suas regras.

A parte difícil é calcular tamanho, complexidade e o nível de indefinição de um produto. Sendo um pouco mais objetiva:

• Se sua aplicação tem mais de ~20 fluxos de negócio, ela não é pequena.
• Se sua aplicação é um monolito, ela não é pequena.
• Se você precisa da ajuda de um domain expert para entender os casos de uso e as regras de negócio da sua aplicação, é uma aplicação complexa.
• Se sua aplicação é data-driven, ou seja, o comportamento dos usuários dita quais funcionalidades serão desenvolvidas ou melhoradas, existem bastantes indefinições.

Exemplos que não se encaixam nos critérios acima

• Aplicações tão simples como um CRUD, que não carregam muita lógica de negócio.
• Aplicações que tem um domínio bem definido e seus casos de uso não diferem muito de aplicação para aplicação, como serviço de autenticação ou serviço de envio de SMS, por exemplo.
• Backend for Frontends

Conclusão

Assim como todos os conceitos, DDD não é bala de prata. Se bem utilizado, ele pode ser um aliado no processo de desenvolvimento de software, mas quando tentamos encaixá-lo onde não é necessário, pode ser que tenhamos ainda mais trabalho e mais complexidade no fim das contas.
Se você viu que a sua aplicação se encaixa nos requisitos descritos acima, eu recomendo que você leia o Domain Driven Design e o Implementing Domain Driven Design para melhor entendimento de como pôr DDD em prática com eficiência.