Depósitos de paquetes y sus interfaces en DDD

Question

En las aplicaciones siguientes a las que trabajé DDD, tendemos a tener una capa de servicio que contiene los servicios + repositorios + las interfaces para repositorios y servicios, todos ellos viven en el mismo ensamblaje, mientras que el dominio modelo vivirá en un ensamblaje diferente. Parece que todo lo que no se ajusta al modelo de dominio está repleto de este gran proyecto.

En una aplicación que sigue los principios y patrones de DDD, ¿cómo empaqueta los repositorios y las interfaces que implementan? ¿Cuáles son las mejores prácticas para empaquetar diferentes partes lógicas de la aplicación de DDD (o empaque en general para el caso)? ¿Debería cada partición lógica vivir en su propia asamblea? ¿Incluso importa?

Answer 1

Me gustaría ver la arquitectura de cebolla. Básicamente, todos los modelos de dominio y las interfaces para los servicios de dominio se consideran esenciales. Las capas dependen solo de las capas que están más cerca del núcleo. Su implementación real es manejada por la infraestructura.

ve aquí http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

En última instancia sus interfaces son lo que define su aplicación. La lógica de cómo se implementa se exterioriza. Así que espero que tenga ensamblados con modelos de dominio y servicios de dominio, una interfaz (por ejemplo, MVC, etc.) y luego un ensamble de infraestructura que implemente cosas como NHibernate para proporcionar datos, etc.

Puede ver varias muestras que implementan la arquitectura en las diversas partes del artículo vinculado. La más simple es aquí https://bitbucket.org/jeffreypalermo/onion-architecture/get/1df2608bc383.zip

Se puede ver las preguntas relacionadas con lo que aquí https://stackoverflow.com/questions/tagged/onion-architecture

El principal beneficio es que es en gran parte los problemas de infraestructura que cambiarán la mayoría de las veces. Nuevas tecnologías de capa de datos, nuevo almacenamiento de archivos, etc. También su dominio central debe ser razonablemente estable ya que no está implementando nada que solo defina por contrato (interfaces) lo que requiere. Al poner los problemas de implementación en una ubicación, minimiza la cantidad de cambios que se requerirán en sus ensamblajes.

Answer 2

Puede encontrar pautas para diseñar sus capas en el DDD book. Es, básicamente, tiene:

• dominio
• Infraestructura
• Aplicación
• IU

Servicios vienen en 3 tipos: servicios de aplicación de capa, la capa de servicios de infraestructura y servicios de capa de dominio, dependiendo en lo que hace el servicio En cuanto a los repositorios, sus contratos (interfaces) a menudo residen en el dominio, mientras que sus implementaciones concretas se encuentran en la capa de infraestructura.

En cuanto a los conjuntos, recomendaría al menos uno por capa. Las asambleas y las dll son sobre reutilización, separación de preocupaciones y desacoplamiento: ¿podré elegir ese dll y soltarlo para volver a utilizarlo en otra aplicación? ¿Podré hacerlo sin arrastrarme por un conjunto de características no relacionadas que traerán complejidad innecesaria a esa otra aplicación? ¿Podré sustituir fácilmente mi dll por otro simplemente cambiando una línea de código en mi módulo de inyección de dependencia? y así.