Tengo problemas para trazar una línea clara entre la presentación y la capa de aplicación en Diseño controlado por dominio.
¿A dónde deben ir los Controladores, Vistas, Diseños, Javascript y CSS?
¿Está en la capa Aplicación o Presentación?
Y si van todos juntos en la misma capa, ¿qué contiene la otra? Esta vacio?
Respuestas:
El hecho de que alguien haya creado y llamado "Capa de aplicación" y "Capa de presentación" no significa que su aplicación deba tenerlos. Debe crear capas DESPUÉS de haber creado una cantidad sustancial de código que haya agrupado y desee nombrar a este grupo en aras de la comunicación entre los desarrolladores y la claridad del código.
Desde el punto de DDD. La capa de aplicación es todo lo que no es la capa de dominio. Que incluye lógica de aplicación, presentación y servicios de aplicación.
Hay una gran diferencia entre la capa de aplicación y la capa de presentación desde un punto de vista DDD.
Aunque DDD se centra en cómo modelar el dominio utilizando los bloques de construcción DDD y conceptos tales como contextos delimitados, lenguaje ubicuo y demás, sigue siendo vital identificar y separar claramente las diversas capas en su aplicación.
La arquitectura juega un papel importante en la implementación de una aplicación DDD exitosa. Una arquitectura famosa que ganó mucha expectación últimamente es la arquitectura de cebolla:
En este diseño, la capa de IU / Presentación y la capa de aplicación están claramente separadas. Fusionar los 2 juntos introduce un acoplamiento estrecho entre 2 capas que tienen claras preocupaciones y responsabilidades separadas.
La capa Presentación solo debe contener la lógica de presentación. Evite las IU inteligentes que saben demasiado. Esto alberga principalmente los Controladores y vistas del MVC, además de CSS, JS, plantillas, formularios y todo lo relacionado con los objetos de respuesta y solicitud.
Las acciones emitidas a través de la presentación se delegan a la capa de aplicación a través de comandos. La capa de aplicación contiene la lógica de la aplicación. Normalmente se asigna a un caso de uso. Contiene LO que el sistema debe hacer para satisfacer un caso de uso. Un servicio de aplicación típico le pedirá a un repositorio que devuelva un agregado y luego invocará una acción sobre ese agregado.
Eche un vistazo al proyecto de muestra del IDDD de Vaughn Vernon
entry pointy se composition rootcolocan? Siempre pensé que era una responsabilidad de la Applicationcapa. Pero ahora parece que esto es una Presentationcapa.
El diseño dirigido por dominio no tiene nada que ver con la capa de presentación o la capa de aplicación. DDD es una metodología cuyo foco principal está en la capa de dominio. Es decir, DDD no impone restricciones con respecto a ninguna otra capa, excepto la capa de Dominio y Su pregunta también podría formularse en el contexto de cualquier otra metodología.
Dicho esto, es muy común usar una arquitectura de cuatro capas para aplicaciones DDD. Aquí hay un ejemplo de una de esas aplicaciones que muestra las capas y su uso previsto: DDDSample Architecture . Entonces, si elige usar esta arquitectura, sus vistas y diseños irían a la capa Interfaces y los controladores, si son independientes de la interfaz, irían a la capa Aplicación.
También podría elegir cualquier otro tipo de arquitectura, ya que he dicho que DDD no impone restricciones. Existen muchos marcos MVC que tienen diferentes estructuras y, sin embargo, también podrían usarse para aplicaciones DDD. Luego, por supuesto, colocaría Sus vistas y diseños en consecuencia.