Relaciones muchas-a-muchas en DDD

Question

Soy nuevo en DDD y estoy atrapado en relaciones de muchos a muchos. P.ej. tenemos dos raíces agregadas: tareas y trabajadores.

El contrato definitivamente no es raíz agregada, porque no tiene sentido sin Tarea y Trabajador. Por lo tanto, debe ser parte de un agregado. ¿Pero a qué agregado debería pertenecer? Necesitamos conocer los costos resumidos de todos los contratos de tareas y los costos resumidos de todos los contratos de los trabajadores. Y es natural para mí tener una colección de 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 para el modelo anémico. ¿Hay una forma común de tratar con las relaciones de muchos a muchos y preservar el modelo de dominio de alcance?

Gracias!

Answer 1

Siguiendo preguntas relacionadas vinculados en la barra lateral, me encontré con este interesante artículo:

DDD & Many to Many Object Relational Mapping

Parece recomendar lo que estaba pensando intuitivamente todos modos: que no es, de hecho, natural para el trabajador y la tarea asumir 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 tener una dependencia de la entidad contractual.

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 dices "Contrato definitivamente no es una raíz agregada, porque no tiene sentido sin Tarea y Trabajador". Esa es en realidad la razón exacta por la que el Contrato es la raíz agregada.

Por lo tanto, mi sugerencia, con una visión de arootbeer de los comentarios incorporado:

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 de worker y task es ciertamente cierto, pero eso no significa que no sea una raíz agregada en sí misma.

Presumiblemente Contract tiene su propia lógica para calcular su costo, en función de algunos atributos de task y worker asociados a ella. Del mismo modo, existe un contexto que contiene Task y Worker que no son relevantes para Contract.

La brecha que necesita para saltar está moviendo el contexto relevante en el objeto Contract. Deje que almacene la tasa de worker y el período task (además de los ID respectivos, que solo se modelan implícitamente más arriba) y calcule el costo de forma dinámica.

--EDIT--

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