Cómo implementar un kernel compartido (DDD) en .Net correctamente

Question

Tengo una aplicación heredada. Estoy rediseñando porque es lo que llamamos una "bola de lodo" en este punto, sin capas o SOC en absoluto. El equipo está acostumbrado a trabajar de forma modular, lo que significa que hay un equipo que trabaja en "capacitación", "Oportunidades de trabajo", uno que trabaja en un módulo que gestiona "Planificación de tareas (militar)". Tenemos un sitio web que expone estas áreas a nuestros clientes como un portal de servicios, una base de datos y algunas aplicaciones externas a las que damos servicio.

Estoy haciendo un buen rediseño de la mayoría de las capas, excepto cómo particionar el dominio correctamente (Debo mencionar en este punto que estamos usando .Net 4.0). Mi idea original era que estos eran contextos delimitados debido a la forma en que estaban trabajando, realmente parecían tener diferentes grupos de usuarios, pero ahora creo que la realidad es que las personas que usan este sitio pueden y usan muchas áreas a la vez. Claro, algunos grupos SOLO usan un servicio exclusivamente, pero muchos usan varios. El objetivo del sitio es la gestión integral de los "miembros". Entre los módulos, tenemos clases exclusivas para el módulo y luego tenemos algunas clases compartidas, por ejemplo, el concepto de miembro es conocido y utilizado por todos los módulos. El miembro es realmente un concepto central, el sitio agrega valor al rastrear la información de los miembros en todas estas áreas a la vez. Eso es básicamente eso, algunas áreas estrechamente relacionadas pero separadas en el sistema y un área compartida. Espero que sea lo suficientemente claro como para responder la pregunta que tengo.

Estoy pensando que todavía tendría un kernel compartido, incluso si no se trata de contextos delimitados, para las entidades comunes y las interfaces de dominio compartido, como una interfaz de depósito genérica. ¿Sería prudente poner todo el código común (repositorio genérico, modelo de dominio central, kernel compartido, etc.) en el mismo espacio de nombre o jerarquía de espacio de nombres y debería aislar este espacio de nombres en su propio ensamblaje? Del mismo modo, ¿podría dividir cada área ("capacitación", "Oportunidades" ...) en sus propios ensamblajes o es mejor tenerlos todos en un ensamblaje y dividirlos de manera lógica por espacio de nombres. Por un lado, es un poco más fácil ver los módulos divididos físicamente, pero me preocupan las situaciones en las que dos módulos deben trabajar juntos para resolver un problema. ¿Cómo se comunicarían y mantendrían las cosas acíclicas (a través de servicios en la capa de aplicación que estoy adivinando)?

modo (resumen de las opciones):

Domain.Model (DLL) - Domain.Model.Core - Kernel (compartido entidades y modelo básico de dominio) - RepositoryFramework - etc. .. - Domain.Model.Training - Domain.Model.Opportunities ...

o

Domain.Model.Core

Domain.Model.Training (DLL)

Domain.Model.Opportunities (DLL) (cómo hacer el entrenamiento y las oportunidades de trabajar juntos?)

muchas gracias por su tiempo,

Answer 1

En el caso del diseño físico, pondría todo (todo el modelo de dominio) en un ensamblaje. Usar ensamblajes separados no le proporciona ningún beneficio mientras complica las cosas y aumenta el tiempo de compilación.

Por otro lado, si existe el riesgo de que algunos desarrolladores utilicen clases inadecuadas (las que pertenecen a otro módulo/contexto), puede ser conveniente dividir la lógica en ensamblado común (núcleo, núcleo compartido) y montajes específicos para cada módulo/contexto.

En el caso del diseño lógico (espacios de nombres), le daría a cada parte un espacio de nombre separado (por ejemplo, DomainModel.Core, DomainModel.Training). A veces es aconsejable ir un paso más allá y poner cada Agregado en su propio espacio de nombres. Evita cruzar accidentalmente los límites agregados ya que requiere una directiva separada de 'uso'.

esperanza que tiene sentido.