Definir límites y comunicar entre raíces agregadas

Question

Me vendría bien un poco de ayuda para comprender un poco el modelo de mi dominio y asegurarme de que estoy abordando el diseño correctamente.

Tengo una raíz agregada llamada Departamento.El objeto del departamento tiene varios tipos de valor infantil que ayudan a definir la noción comercial de un 'departamento'. En mi interfaz de usuario, los usuarios pueden enumerar, crear, editar y eliminar objetos de departamento.

Tengo otra raíz agregada llamada Proyecto.Un proyecto tiene varios tipos de valores secundarios, pero también tiene una relación con un departamento en el sentido de que cada proyecto es "propiedad" de un departamento.Los proyectos se pueden crear, editar, eliminar, etc.y hacerlo no tiene ningún impacto en el departamento, mientras que eliminar un departamento también elimina cualquier proyecto que posea.

Mi interfaz de usuario mostrará una lista de proyectos según los departamentos a los que el usuario actual está autorizado a acceder.Es posible que puedan acceder a más de un departamento.Cuando se muestra como elemento de lista y en detalle, necesito mostrar el logotipo del Departamento con el Proyecto.

Lo primero que pensé fue que el Proyecto era una raíz agregada con una propiedad ID de Departamento simple que podía usarse para "buscar" el Departamento.Pero ahora estoy empezando a pensar que en realidad sólo tengo una raíz agregada:Departamento.

¿Qué opinas?

ACTUALIZAR

No sé si es clave para la discusión o cambia algo, pero se me ocurrió lo siguiente después de leer las primeras respuestas.

El departamento parece tener dos contextos:

1. Como una entidad independiente que respalda la modificación.
2. Como hijo de un proyecto, en cuyo caso contiene datos de solo lectura y sin comportamiento.

Esto me hace pensar que debería tener dos 'objetos' en mi modelo, una raíz agregada para el caso n.º 1 y un tipo de valor para el caso n.º 2.¿Estoy en el camino correcto?

Answer 1

Dado que el Proyecto no puede existir sin un Departamento, probablemente no sea una Raíz Agregada.Según su descripción, parece que solo tiene un AR: el Departamento, que utiliza para administrar los proyectos dentro de él.

Si su comportamiento es principalmente CRUD, no recomendaría crear un modelo de dominio completo para ello, ya que probablemente existen enfoques más simples que puede adoptar.

ACTUALIZARComo mencionas, es posible que tengas 2 contextos acotados aquí.Aquel donde el Departamento es una AR y los Proyectos son entidades de esta AR.En este contexto usted realizaría operaciones en sus Departamentos.En un segundo BC, su Proyecto podría ser el AR y los Departamentos podrían ser entidades u VO.Esto le permitiría trabajar directamente con proyectos.

También recomendaría repasar esto con su experto en el dominio y ver si estos conceptos encajan bien en su UL, o tal vez buscar algún concepto faltante que pueda aclarar su modelo.Especialmente buscaría un concepto que pudiera vincular proyectos con departamentos.

Answer 2

Creo que es perfectamente defendible que tanto el Proyecto como el Departamento sean raíces agregadas, ya que ambos se administran de forma independiente.

Es decir, cada Proyecto y cada Departamento tiene algún tipo de identificador único, y si bien puede agregar Proyectos a Departamentos, los Proyectos en sí probablemente sean lo suficientemente complicados (con sus propios ciclos de vida, sus propios objetos secundarios, etc.) como para garantizar el estado de raíz agregada.

Sólo hay que llevar una referencia del Departamento en cada Proyecto.

Answer 3

Algunas preguntas sencillas que deben responderse:

1) ¿Puede el objeto de dominio del departamento vivir solo sin el objeto de dominio del Proyecto?- En caso afirmativo, entonces el departamento es un agregado.

2) ¿El objeto de dominio del Proyecto puede vivir por sí solo? En caso afirmativo, entonces el Proyecto también es un agregado.

3) ¿El Proyecto tiene relación con un Departamento? Entonces debería ser parte del agregado del Proyecto expuesto como Departamento de propiedad.

4) ¿El Departamento tiene relación con uno o más objetos del Proyecto? El agregado del Proyecto debe ser parte del objeto agregado del Departamento.

Por lo tanto, al utilizar el objeto agregado Departamento, es posible que necesite acceder a la lista de objetos Proyecto(s) y, una vez que tenga el objeto Proyecto, es posible que necesite acceder al objeto Departamento.Es una referencia circular que está obsoletamente bien.

Es un ejemplo típico de que el empleado tiene un gerente y el gerente tiene una lista de empleados.