muchos - proyecto mvc c#

Relaciones de muchos a muchos en DDD

Question

Soy nuevo en DDD y tengo muchas relaciones con muchos. Por ejemplo, tenemos dos raíces agregadas: tareas y trabajadores.

El contrato definitivamente no es una raíz agregada, porque no tiene sentido sin Tarea y Trabajador. Por lo tanto, debe ser parte de algún agregado. ¿Pero a qué agregado debe pertenecer? Necesitamos conocer tanto los costos de resumen de todos los contratos de tareas como los costos de resumen de todos los contratos de trabajadores. Y es natural para mí tener contratos tanto en Tarea como en Trabajador.

Bueno, puedo mover el cálculo de costos al servicio de dominio, pero me temo que es un paso adelante hacia el modelo anémico. ¿Hay una forma común de lidiar con relaciones de muchos a muchos y preservar el modelo de dominio de alcance?

¡Gracias!

Answer 1

Al seguir las preguntas relacionadas vinculadas en la barra lateral, encontré este interesante artículo:

DDD y muchos a muchos mapeo relacional de objetos

Parece recomendar lo que estaba pensando intuitivamente de todos modos: que, de hecho, no es natural que el trabajador y la tarea asuman una dependencia del contrato. Es decir, el concepto de "trabajador" sigue siendo significativo sin el concepto de "contrato" (y de manera similar para la tarea), por lo que la entidad que incorpora ese concepto no debe depender de la entidad contratante.

Para mostrar los contratos asignados a una tarea determinada, o los contratos asignados a un trabajador determinado, deberá ejecutar una consulta de dominio. De hecho, este es un uso apropiado para un servicio de dominio, y refleja mejor la realidad de su dominio si lo piensa.

También observo que usted dice "El contrato definitivamente no es una raíz agregada, porque no tiene sentido sin Tarea y Trabajador". Esa es en realidad la razón precisa por la que el Contrato es la raíz agregada.

Entonces, mi sugerencia, con la perspectiva de arootbeer de los comentarios incorporados:

Answer 2

Contract me parece ser un objeto de primera clase en su diseño. Su afirmación de que no tiene sentido fuera del contexto tanto de un worker como de una task es ciertamente cierta, pero eso no significa que no sea una raíz agregada por derecho propio.

Presumiblemente, el Contract tiene su propia lógica para calcular su costo, en función de algunos atributos de la task y del worker asociado. De manera similar, hay un contexto que contienen Task y Worker que no son relevantes para el Contract .

La brecha que necesita para saltar es mover el contexto relevante al objeto de Contract . Deje que almacene la tarifa del worker y el período de la task (además de las respectivas ID, que solo se modelan implícitamente más arriba), y calcule el costo de forma dinámica.

--EDITAR--

Como Domenic afirma, su comentario es un buen candidato para una pregunta de seguimiento. Pero diré que una vez que obtenga las ID de Task y Worker en el Contract , la presentación de informes se convierte en una tarea trivial.