Arquitetura para o DDD

Continuando a série sobre o Domain Driven Design iniciada aqui, vamos agora comentar sobre como arquitetar as camadas da aplicação de modo a utilizar um Domain Model rico como a "base" do desenvolvimento.

Antes de mais nada, convém salientar que essa não deve ser vista como a única arquitetura que existe e que irá atender a todos os sistemas e situações do mercado. Trata-se apenas da arquitetura mais adequada a um projeto que trabalhe sob as premissas do DDD.

As camadas são representadas como abaixo:

Explicação sobre as camadas:

É importante dizer que não considero a camada Application como mandatória; ela é criada apenas se realmente adicionar valor à aplicação. Como a camada Domain é bastante rica em funcionalidades, muitas vezes não é necessário implementar mais essa divisão.

A criação de um Domain Model  traz uma série de vantagens para aplicações de larga escala e/ou complexas. Como bem disse Martin Fowler em PoEAA: "se você utilizar DDD para um projeto, você provavelmente irá cogitar utilizar a mesma técnica para outros (mesmo para os pequenos)."

Um design focado na criação de um Domain Model tem melhor manutenção no longo prazo devido à clareza da relação entre o negócio e a implementação. Além disso, é uma importante ferramenta para evitar a duplicação de código. Também aumenta a testabilidade do sistema.