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, como los Aggregate normales. 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 y Value objects que contiene, Application services y Domain services que lo usan y los Command use case y Query use case que lo solicitan.
Como observación, decir que el Aggregate root marca el límite de lo que sería un Module. No puede haber dos Aggregate root en un Module, pero sí varios Aggregate.
¿Qué valor me aporta implementar un Aggregate root?
- 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.
¿Cómo se expresa esta carta en el mundo real?
Como indica el icono de arriba a la izquierda, corresponde a una clase.
|
|