Domain Driven Design - Preciso disso ? Quando usar ?

 Hoje veremos em qual contexto a aplicação do Domain Driven Design é pertinente.

O DDD (Domain Driven Design) é uma abordagem ao design de software que se baseia no conceito de domínio.

Onde:  "Um domínio é um campo de estudo que define um conjunto de requisitos, terminologia e funcionalidade comuns." - Wikipedia

E de onde veio o DDD ?

Foi Eric Evans, que apresentou o DDD com seu livro: Domain-Driven Design  Tackling Complexity in the Heart of Software, que numa tradução livre seria: Design Orientado a Domínio: Combatendo a Complexidade no Coração do Software, onde ele define um conjunto de conceitos básicos para nos apresentar o DDD.

Neste artigo eu não vou me ater aos conceitos do DDD vou apenas focar quando é pertinente usar o DDD em um projeto de Software.

Quando devo usar o DDD ?

Qualquer tecnologia  que o homem crie tem o seu limite e com o DDD isso não é diferente.

O DDD não é a bala de prata ou a panacéia universal que vai resolver todos os problemas no seu projeto de software.

Existem diferentes tipos de projetos de software e o DDD é aplicável somente a uma fração deles.

Cada projeto de software possui um conjunto de atributos que podem variar, mas que podemos resumir em:

  1. A quantidade de dados gerenciada
  2. O desempenho
  3. A complexidade da lógica do negócio
  4. A complexidade da tecnologia envolvida no projeto

O DDD não vai te ajudar a gerenciar melhor os dados, nem vai te ajudar a aumentar o desempenho da sua aplicação e nem vai te ajudar na complexidade da tecnologia usada no seu projeto. Existem outras ferramentas que você poderá usar para te ajudar nesses quesitos.

Para não perder tempo podemos dizer que o DDD é aplicável apenas quando a complexidade da lógica do negócio é alta.

Em uma aplicação que faz um CRUD realizando apenas operações de leitura, inclusão, alteração e exclusão de dados, usar DDD seria como usar um tanque para matar uma mosca.

Já em um sistema ERP que automatiza grande parte das operações de uma empresa e que precisa modelar todos os processos onde a empresa atua, tendo que tratar assim com uma grande complexidade nas regras de negócio, usar DDD é pertinente e se justifica.

Dessa forma, as técnicas propostas pelo Domain Driven Design serão úteis e farão sentido, valendo a pena serem aplicadas, em projetos onde a complexidade da lógica de negócio justificar a sua adoção.

Percebeu que DDD não é sobre escrever código mas sobre todo o processo antes do código ser escrito que envolve o conhecimento do domínio do negócio e sua complexidade.

Para projetos simples Não usar DDD não significa que você não esta fazendo do jeito certo.

Na verdade usar DDD em um projeto de software que realiza apenas um CRUD é estar fazendo do jeito Errado.

Assim, não se deixe levar pela onda DDD e não se sinta incomodado porque o seu projeto não usa DDD.

Se ele não precisa disso porque você teria que aplicar o DDD só porque o assunto DDD esta em voga ?

Cabe ressaltar que você deve conhecer a fundo o DDD para ter condições de poder decidir e julgar quando ele é aplicável ou não, se vale a pena ou não.

Fora desse contexto usar DDD apenas para dizer que esta usando DDD é jogar tempo e dinheiro pelo ralo.

Disse Jesus: "Se, pois, o Filho vos libertar, verdadeiramente sereis livres."
João 8:36

Referências:

José Carlos Macoratti