Especificaciones
Ya que engloba otros Aggregates y Value objects, no debería ser más complejo que lo que contiene, con lo que le daremos una complejidad de 3, equivalente a un Aggregate normal. Aunque pude subir de complejidad si la gestión de los eventos también lo es.
Tiene como misión principal englobar los elementos fundamentales del negocio.
Como características más concretas, podemos decir que es el responsable de otros Aggregate. Tiene un identificador que lo hace único en el Domain. Preferiblemente se debe crear usando composición. Si hay que cambiar algo de los Aggregate o Value objects que contiene, han de pasar por sus manos.
Un tema importante es poder guardar dentro de si todos los cambios que le han sucedido en forma de Domain events desde que se creó, o en su defecto, se recuperó de Persistence. Esto nos será muy útil en el futuro si vamos a usar una estrategia de publicar Domain events.
Se suele relacionar con los otros Aggregate, Value objects y Domain events que contiene, Domain services que lo usan y los Command use case y Query use case que lo solicitan.
¿Qué valor me aporta implementar un Aggregate root?
Un Aggregate root es fundamental para organizar y gestionar la consistencia de un grupo de entidades relacionadas.
- De igual forma que un Aggregate, un Aggregate root encapsula una unidad de información coherente.
- Los Aggregates cambian a través del Aggregate root, que es quien tiene toda la foto general de las reglas del dominio a las que representa.
- Los cambios en el estado de un Aggregate, incluidas sus entidades internas, suelen realizarse dentro de una sola transacción. Esto asegura que todos los cambios se apliquen o ninguno, manteniendo la consistencia.
¿Cómo se expresa esta carta en el mundo real?
Como indica el icono de arriba a la izquierda, corresponde a una clase.
|
|