Está en el camino correcto sobre DDD en función de cómo delgada/gruesa que las capas de servicios de dominio son &. DDD dice que el conocimiento (es decir, la lógica de negocios) debe crujirse en el modelo de dominio. Mover las preocupaciones de acceso a datos a DAL está en línea con DDD, pero creo que mover la lógica de negocios a una capa de servicios no lo es. Si tiene una capa delgada de "Modelo de datos" de dominio (principalmente para entidades) y una capa de Servicios gruesa (principalmente para "lógica de negocios"), puede tener un anemic domain.
Además, técnicamente no hay "Capa de servicio" en DDD. Puede haber una "capa de aplicación", pero debe ser delgada, y solo responsable del flujo de aplicaciones/administración de las duraciones de la clase de dominio. Esto es esencialmente lo que hacen los Controladores en .NET MVC, administra el flujo de aplicaciones en el contexto de la http de la web.
Si el relleno de toda la lógica dentro del modelo hizo su código excesivamente complicado, estaría interesado en escuchar ejemplos de lo que entendemos por "demasiado complicado". Podrías modelar correctamente un dominio complejo, o hay posibilidades de que hayas recurrido a los patrones DDD para simplificar las cosas. Diría que como lo mencionaste en tu pregunta, el arco no es DDD. Me acaba de llamar "arquitectura de capas", pero eso es porque yo prefiero usar el término "nivel" Sólo cuando se habla de arco física. Sin embargo, su arquitectura lógica está en capas.
Me gusta mucho que Darin vincule al arco de cebolla en su respuesta. Me estoy convirtiendo en un gran admirador de esto, y me parece que no es exclusivo de DDD en absoluto.Si su código usa inyección de dependencia para resolver dependencias de interfaz con implementaciones en tiempo de ejecución, puede tener una forma de arco de cebolla. Por ejemplo, ¿define alguna interfaz en su DAL? ¿Las implementaciones de esas interfaces se resuelven en tiempo de ejecución?
Aquí hay un ejemplo de un arco que estoy comenzando a usar en mis nuevos proyectos. Es una combinación de cebolla + DDD:
API Proyecto/Estructura: interfaces, enumeraciones, clases y métodos de extensión genéricos utilizados por todas las demás capas. No necesita estar separado del dominio, pero puede.
Domain Proyecto/Ensamblaje: todas las entidades y lógica de negocios. Depende de API solamente. Utiliza patrones DDD como fábrica, servicio, especificación, repositorio, etc. También contiene más interfaces específicas de dominio que no están definidas en la API.
Impl Proyecto/Ensamblaje: implementaciones de interfaces definidas en API y Domain. Aquí es donde se implementa el EF DbContext, así como cosas como el registro, el envío de correo electrónico, etc. Todas estas implementaciones son de inyección de dependencia, por lo que técnicamente podría tener varios proyectos/ensambles Impl.
UI Proyecto/Ensamblaje: Este es el proyecto MVC. Los controladores consumen la superficie del dominio directamente y no pasan por una aplicación o capa de servicio. Cualquier dependencia de interfaz en fábricas, servicios, repositorios, etc., se inyecta en el dominio por el controlador utilizando MVC IoC (inyección de constructor).
Puse una capa de API en el núcleo, pero podría combinar los proyectos de API y de dominio en uno. De cualquier manera, la gran parte carnosa de la cebolla es el Dominio, y tiene estratificación interna. Por ejemplo, los Servicios pueden depender de Fábricas, que dependen de Repositorios, que dependen de Entidades.
El proyecto Impl es lo que usted ve como la piel de cebolla "Infraestructura" en el diagrama de Palermo. Está en el borde exterior junto con la IU, y no contiene ningún conocimiento específico del dominio. Sabe cómo enviar correos electrónicos, almacenar/recuperar datos usando EF, etc. Si lo desea, puede tener más de 1 de estos; por ejemplo, 1 Impl para acceso a datos, 1 Impl para tratar correo, etc.
MVC tiene los Controladores y Vistas, y se concentra en la UI y el flujo de aplicaciones web. Cualquier cosa que requiera conocimientos específicos del dominio se delega en el dominio, y las clases de dominio se inyectan en el controlador. Esto significa que cualquier interfaz inyectada por el constructor en clases de dominio se resuelve automáticamente por el contenedor IoC.
Como nota final, la programación contra las interfaces definidas en las clases API y Dominio significa que puede probar el proyecto de dominio por separado del proyecto MVC.
¿Tiene algún buen ejemplo de proyectos ASP.NET MVC basados en DDD? ¿O los que utilizan la arquitectura que describes? He estado tratando de leer el código de todos los proyectos ASP.NET MVC que pueda para determinar qué prácticas se están utilizando, pero es extremadamente difícil. –
Me gustaría chatear sobre esto con usted antes de publicar una respuesta a su comentario: http://chat.stackoverflow.com/rooms/9000/danludwig-private-room – danludwig
¡Respuesta tan interesante! No sé cómo google me ha dirigido a esta publicación anterior, pero es realmente bueno. ¿Podría escribir un artículo en Code Project sobre DDD y Onion Architecture con un ejemplo :) O ya lo ha hecho: D – Celdor