DDD - Domain Driven Design

Objetivo

É uma filosofia, um modo de pensar e organizar as regras de negócio, o negócio é o centro da aplicação ela importa mais do que todas as outras frentes. O objetivo é fazer pesquisas de mercado, conversar com clientes, observar o funcionamento do negócio, viver o negócio de modo que todas as regras fiquem claras, trabalho que geralmente é feito pelo PO ou PM.

Depois de ter em mãos todas essas regras, elas são refinadas e são trasnformadas em códigos, classes que vão representar o que é chamado de Domínio. Todas as regras mapeadas devem estar centralizadas na classe de domínio serão recebidas via construtor e repassadas para as propriedades, as validações podem ocorrer no próprio contrutor ou em métodos da mesma classe.

É difícil falar de DDD sem falar de arquitetura pois estão ligados um complementa o outro, é difícil seguir DDD com uma arquitetura que não foi projetada para seguir os padrões de arquitetura limpa, onde o Domínio é protegido, o que isso quer dizer ?

Proteger o domínio é fazer com o que ele não tenha dependencia de nenhuma outra camada do código ele é independente. Temos muitos projetos legados que podemos notar uma completa mistura, onde classes de domínio instanciam outras classes para fazer as validações, criando depdendencias e isso é negativo pois ferem os princípios e criam alto acoplamento, em caso de execução de testes automatizados certamente sera trabalho ou até mesmo impossível de testar essas classes.

Exemplo prático

Vamos então simular que acabamos de receber do PO e PM, uma lista de regras de negócio de um case que foi estudado por 3 semanas e foi considerado promissor ao mercado e vai trazer receita para a empresa. Então temos a missão de tornar essas regras de negócio em código de modo que temos agora a missão de dar o ponta pé inicial desse sistema. Ou seja se fizermos uma arquitetura mal pensada o sistema não vai conseguir escalar depois. Olha a responsa ...