Un agregado es un patrón de diseño en DDD. El agregado es un objeto dependiente de un objeto de dominio, por sí mismo tiene un significado, pero a su vez depende totalmente del objeto de dominio raíz. Por ejemplo: una partida contable debe de tener un cargo y un abono, el objeto de dominio es la partida, tanto el cargo como el abono son sus agregados. Estos tienen un significado propio que no puede ser entendido sin su objeto raíz. Otro ejemplo podrían ser los conceptos de una factura, esta requiere de un concepto que la justifica, pero un concepto sin factura sirve para poco hablando conceptualmente.
Un agregado debe tener un objeto de dominio asociado.
Es fácil confundir un agregado con un objeto de valor, ambos son objetos de alto valor conceptual en DDD, incluso un objeto de valor puede considerarse un agregado. El punto clave es la dependencia, el agregado si o si debe ser referenciado al objeto raíz, si un agregado hace referencia a más de un objeto de dominio, entonces no es agregado. También, la referencia de un objeto raíz hacia un agregado puede ser bidireccional. O sea, el objeto raíz hace referencia al agregado y el agregado posee una referencia al objeto raíz. Este tipo de construcción debería hacerse si, y solo si es estrictamente necesario en el diseño del sistema. Demasiadas referencias innecesarias son peligrosas.
Los agregados no son colecciones.
Los agregados no son un tipo de dato. Si bien un agregado internamente puede tener una colección para su trabajo personal, esto no significa que deba de considerarse estas estructuras de datos inmediatamente como agregados. Los agregados no son estructuras de datos o tipos primitivos, son unidades conceptuales de alto nivel.
Los agregados no deben ser un reflejo de la base de datos.
Otro error común es querer representar las relaciones de tablas que componen el modelo de datos, como los objetos de dominio y agregados en las reglas de negocio. Hay cierta relación entre las entidades del modelo de base y el diseño de las reglas de negocio, lo sé, pero rara vez son equivalentes. Es preferible modelar las relaciones entre los objetos de dominio y los agregados manualmente sin hacer ninguna referencia al ORM, las tablas, Entity Framework o cualquier intermediario con el medio persistente. La mayoría de las relaciones que se generan son innecesarias a la hora de hacer un diseño apegado al problema.
Los agregados imponen restricciones de comunicación.
Cuando limitas por diseño el número de referencias o interacciones que puede tener un objeto, reduces el riesgo de tener efectos colaterales en los cambios. Los agregados son elementos secundarios pero indispensables para completar una acción. Un objeto de dominio con sus agregados debe ser lo suficientemente atómicos para completar una operación y lo suficientemente grandes para tener un significado útil. Un escenario de agregados anidados o múltiples referencias entre objetos puede generar caos si se mezcla con eventos. Menos es mejor en estos casos.
Autor imagen: Glen Bledsoe
Referencias:
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
