Apresentação VS camada de aplicação no DDD

9

Tenho problemas para desenhar uma linha clara entre a camada Apresentação e Aplicativo no Design Orientado a Domínio.

Para onde devem ir os arquivos Controladores, Vistas, Layouts, Javascript e CSS?

Está na camada Aplicativo ou Apresentação?

E se eles forem todos juntos na mesma camada, o que contém a outra? Está vazio?

architecture domain-driven-design layers

— Matthieu Napoli
fonte

7

Só porque alguém criou e nomeou "Camada de aplicativo" e "Camada de apresentação" não significa que seu aplicativo deve tê-lo. Você deve criar camadas DEPOIS de criar uma quantidade substancial de código que agrupou e desejar nomear esse grupo para fins de comunicação entre desenvolvedores e clareza de código.

Do ponto de DDD. Camada de aplicação é tudo o que não é camada de domínio. O que inclui lógica de aplicação, apresentação e serviços de aplicação.

— Eufórico
fonte

2

Obrigado. De fato, você me fez perceber que, no meu caso, separar Aplicativo e Apresentação é inútil. Simplicidade primeiro!

— Matthieu Napoli

Se o DDD tiver API REST em vez de interface do usuário na camada de apresentação, a API REST seria uma aplicação ou camada de apresentação. Agora estou confuso, desde que eu tinha certeza de que API REST é uma camada de apresentação ..

— Dario Granich

8

Na verdade, o DDD prescreve quatro camadas na seguinte ordem, da mais alta para a mais baixa: Apresentação, Aplicativo, Domínio, Infraestrutura. Portanto, a camada Aplicativo não inclui "apresentação". Além disso, é sempre uma boa ideia decidir sobre as camadas antes que uma quantidade significativa de código seja escrita, pois não se trata apenas de agrupar o código, mas também de restringir a direção das dependências em tempo de compilação.

— Rogério

11

Há uma grande diferença entre a camada de aplicação e a camada de apresentação do ponto de vista DDD.

Embora o DDD se concentre em como modelar o domínio usando os blocos de construção e os conceitos do DDD, como contextos limitados, linguagem onipresente e assim por diante, ainda é vital identificar e separar claramente as várias camadas do seu aplicativo.

A arquitetura desempenha um grande papel na implementação de um aplicativo DDD bem-sucedido. Uma arquitetura famosa que ganhou muito hype ultimamente é a arquitetura da cebola:

insira a descrição da imagem aqui

Nesse design, a camada de interface do usuário / apresentação e a camada de aplicativo são claramente separadas. A mesclagem das duas introduz um acoplamento rígido entre duas camadas que têm preocupações e responsabilidades separadas e claras.

A camada Apresentação deve abrigar apenas a lógica da apresentação. Evite UIs inteligentes que sabem demais. Isso abriga principalmente os Controladores e visualizações do MVC, além de CSS, JS, modelos, formulários e tudo o que se relaciona a objetos de resposta e solicitação.

As ações emitidas por meio da apresentação são delegadas à camada de aplicativo por meio de comandos. A camada do aplicativo contém a lógica do aplicativo. Normalmente, ele é mapeado para um caso de uso. Ele contém o que o sistema deve fazer para satisfazer um caso de uso. Um serviço de aplicativo típico solicitará que um repositório retorne um agregado e invoque uma ação nesse agregado.

Dê uma olhada no projeto de amostra do IDDD de Vaughn Vernon

— Songo
fonte

2

+1. É assim que eu implementei meu projeto. Imediatamente, consegui obter ganhos com isso. Desde que eu abstraí para uma camada de aplicativo, pude ter várias camadas de apresentação. Por exemplo, nossa API da Web e nosso site consomem a camada de aplicativo, que economiza muito tempo e código duplicado, pois meu aplicativo da Web não precisa enquadrar mensagens de e para a API da Web e mantém toda a lógica em sincronia entre os dois.

— Sinaesthetic

Onde estão entry pointe composition rootcolocados? Eu sempre pensei que era uma responsabilidade da Applicationcamada. Mas agora parece que isso é uma Presentationcamada.

— Denis535

2

O Design Orientado a Domínio não tem nada a ver com a camada Apresentação ou a camada Aplicativo. DDD é uma metodologia cujo foco principal está na camada Domínio. Ou seja, o DDD não impõe nenhuma restrição em relação a qualquer outra camada, exceto a camada Domínio, e Sua pergunta também pode ser feita no contexto de qualquer outra metodologia.

Dito isto, é muito comum usar uma arquitetura de quatro camadas para aplicativos DDD. Aqui está um exemplo de um desses aplicativos mostrando as camadas e seu uso pretendido: Arquitetura DDDSample . Portanto, se você optar por usar essa arquitetura, suas visualizações e layouts iriam para a camada Interfaces e os controladores, se independentes da interface, iriam para a camada Application.

Você também pode escolher qualquer outro tipo de arquitetura, como eu disse que o DDD não impõe restrições. Existem muitas estruturas MVC por aí que possuem estruturas diferentes e, no entanto, também podem ser usadas para aplicativos DDD. Então, é claro, você colocaria Seus pontos de vista e layouts adequadamente.

— zafarkhaja
fonte