Arquitetura em Camadas - DDD

Existem várias maneiras de dividir um sistema de software, mas por questões de convenções e experiência a arquitetura em camadas é a mais adotada. A arquitetura de camadas nos ajuda a ter alta coesão, baixo acoplamento e separar as responsabilidades.

Alguns arquitetos de software se preocupam muito mais com a infraestrutura (frameworks e tecnologias) da arquitetura do que com o problema que o software se propõem a resolver. Uma arquitetura de ponta pode trazer boa resposta no desenvolvimento do sistema, mas se toda essa tecnologia não conseguir resolver o problema proposto, a arquitetura não conseguiu agregar valor ao cliente.

As camadas de uma arquitetura devem fazer algum sentido, devem separar responsabilidades, cada camada deve se especializar em um aspecto do sistema, além de permitirem uma manutenção mais barata. Algumas vezes criamos camadas apenas por ser um padrão, em algum momento um arquiteto definiu que em seu software para que um objeto fosse persistido em banco de dados, ele precisaria passar por todas as camadas do sistema até chegar a persistência, mas isso não deve ser tomado como uma verdade absoluta, podemos está apenas gerando uma camada para trafegar objetos, uma camada que não tem função alguma no sistema, mas como cada caso é um caso, uma camada a mais ou a menos pode ser adequada, como dito o importante é que a camada deve ter uma responsabilidade, senão, ela não deve existir.

A maior parte das arquiteturas bem sucedidas de aplicações que utilizam o DDD faz uso das quatro camadas abaixo:

Camadas básicas de uma aplicação com DDD 

Interface de Usuário: Responsável por apresentar informações tanto de entrada quanto de saída de forma amigável ao ator, e interpretar seus comandos. Em um sistema Web nesta camada estariam páginas do sistema e todos os arquivos utilizados para a comunicação com o usuário com scripts, imagens, css e etc. Em uma aplicação Desktop teríamos os componentes de G.U.I.

Aplicação: Responsável por trabalhar os objetos para a camada seguinte. Não contém regras de negócio por mais simples que estas sejam e nem conhece o negócio. Em uma aplicação Web teríamos nesta camada os Controladores, Listeners, Servlets, Conversão de Dados, por exemplo.

Domínio: É o coração do sistema, responsável por representar as regras, informações e conceitos do negócio, aqui os objetos são usados e controlados, mas sua armazenagem fica a cargo da infraestrutura. Esta camada deve ser o mais isolada possível do restante da aplicação.

Infraestrutura: Fornece recursos que oferecem suporte para as camadas de cima, como persistências de dados, envio de e-mail, manipulação de arquivos, etc.

Como pode ser visto na figura acima as camadas têm uma dependência vertical e de cima para baixo. A camada de interface depende da aplicação que depende do domínio que depende da infraestrutura. Como apresentado na figura, essa não é uma ordem que deve sempre ser seguida, pode-se ter a aplicação acessando diretamente a infraestrutura ou, a interface se comunicando diretamente com o domínio. O importante é utilizar as camadas necessárias para desenvolver a funcionalidade desejada, se não é necessário passar por uma camada, não precisamos utilizá-la para não torna-la uma camada de trafego, ela pode ser ignorada naquele momento, mas sempre deve ser respeitada a regra de que a camada de cima acessa a de baixo, nunca o contrario, uma camada sempre dependeram da inferior, mas nunca da superior.

Algumas arquiteturas não tem uma distinção clara entre as camadas de interface do usuário e aplicação, outras, utilizam várias camadas de infraestrutura, isso não chegar a ser um problema para o DDD, o DDD requer apenas a existência da camada de domínio, pois é ela que possibilita o Design Dirigido por Modelos. O isolamento do domínio é um pré-requisito para o DDD.

Como os objetos do domínio devem ser isolados das demais camadas, isso permite que estes objetos expressem o modelo de domínio, permitindo que o modelo evolua e se torne rico o suficiente para captar o conhecimento necessário do negócio.