Diseño impulsado por el dominio - Agregar raíces

Question

Estoy luchando con los agregados y las raíces de agregado. Tengo una raíz agregada natural que funciona para aproximadamente el 60% de las solicitudes de los usuarios. Es decir. esas solicitudes se aplican naturalmente a la raíz agregada.

Dentro de mi agregado tengo otra entidad que solo puede existir como miembro de la raíz agregada. Sin embargo, a los usuarios se les informará acerca de este otro objeto de entidad. En ocasiones, tendrá sentido, conceptualmente, que los usuarios operen directamente en este objeto raíz no agregado.

Por lo tanto, creo que tengo un par de opciones:

1. Ellos pueden ser ambas raíces agregados en función de los cuales se solicita la operación por parte del usuario.
2. Todas las operaciones deben pasar por la raíz agregada de nivel superior.

Tenga en cuenta que la raíz de agregado de nivel superior contendrá una colección de esta otra entidad.

---

Ejemplo:

raíz principal agregada: Coche

segunda entidad: Asiento (un automóvil tiene 2 o 4 asientos según el tipo). En mi dominio, los asientos solo pueden existir como parte de un automóvil.

La mayoría de las operaciones en el dominio están en el nivel del automóvil. Entonces ese será un buen candidato para la raíz agregada. Sin embargo, (y estoy luchando por ejemplos aquí), algunas operaciones estarán en el nivel del asiento, p. SpillCoffee, ChangeFabric, Clean ....

¿Tanto el Asiento como el Coche pueden ser raíces agregadas? ¿O debería siempre comenzar con Car?

Gracias

Answer 1

La idea de un agregado es garantizar la consistencia, siendo la raíz responsable de la integridad de los datos y obligando invariantes.

Supongamos que hay una regla como "El tejido de todos los asientos debe ser el mismo", o "solo puede derramar café en el asiento si hay alguien dentro del automóvil". Será mucho más difícil hacer cumplir estos, una vez los clientes podrán cambiar el tejido por separado, o estos invariantes deberán ser forzados al exterior (zona de peligro)

En mi humilde opinión, si la integridad o forzar invariantes no es un problema, entonces los agregados no son realmente necesarios. si es necesario, mi consejo es comenzar todo con el automóvil. Pero siempre piense en el modelo. Si hay invariantes como estos, ¿quién aplica estas invariantes? Luego intente pasar esta idea al código, y todo debería estar bien.

Answer 2

En el caso de un carrito de compras con un carro y artículos de línea, tengo ambos como raíces agregadas ya que a menudo los modifico de manera independiente.

public class Cart : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

public class LineItems : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

Sin embargo, tengo un contexto acotado por separado para las órdenes y en este caso sólo necesita tener una raíz agregada desde que ya no es necesario modificar los artículos de línea independiente.

public class Order : IAggregateRoot 
{ 
    public List<LineItem> LineItems {get;} 
} 

La otra opción es tener una forma de buscar la raíz agregada desde una identificación de usuario.

Car GetCarFromSeatID(guid seatID) 

Answer 3

Probablemente necesite un conocimiento más profundo de algún aspecto del modelo de dominio. Esta pregunta muestra que está a punto de inventar una forma de organizar las entidades para suministrar el sistema, cuando, idealmente, este tipo de preguntas ya están respondidas antes de la implementación.

Cuando esto aparece solo en la implementación del sistema, ya sea que regrese a revisar el dominio o descubrió cierta fragilidad cuya respuesta podría (y debería) agregar cambios en detalles relacionados del negocio para hacer que el dominio sea más rico y mejor modelado .

En el ejemplo del coche, utilicé el enfoque de dos agregados que relacionan diferentes contextos. El primero sería el enfoque de "automóvil tiene asiento", y en este agregado las posibles acciones para "asiento" serían solo las que tienen sentido para "sentarse como parte de un automóvil". Ejemplo: Limpiar

El segundo agregado estaría en el contexto de "asiento", y existirían las posibles acciones y configuraciones para el asiento como independiente. Ejemplo: ChangeFabric, ColorList. De esta manera, el "automóvil" agregado tiene "asiento", pero los clientes pueden conocer el contexto que tiene sentido. Lo cual es peligroso, como dice samuelcarrijo en la publicación anterior. Si las modificaciones entre contextos afectan la integridad del dominio, perderá todo el concepto agregado.