design patterns - patterns - ¿Qué es una raíz agregada?
design patterns pdf (10)
Estoy tratando de entender cómo utilizar correctamente el patrón de repositorio. El concepto central de una raíz agregada sigue apareciendo. Al realizar búsquedas en la web y en Stack Overflow para obtener ayuda con lo que es una raíz agregada, sigo encontrando discusiones sobre ellos y enlaces muertos a páginas que se supone que contienen definiciones de base.
En el contexto del patrón de repositorio, ¿qué es una raíz agregada?
Agregado es donde protege sus invariantes y fuerza la coherencia al limitar su acceso a la raíz agregada de pensamiento. No lo olvide, el agregado debe diseñar según las reglas de negocio de su proyecto e invariantes, no una relación de base de datos. no debe inyectar ningún repositorio y no se permiten consultas.
De un enlace roto :
Dentro de un agregado hay una raíz agregada. La raíz agregada es la entidad principal de todas las demás entidades y objetos de valor dentro del agregado.
Un repositorio opera sobre una raíz agregada.
Más información también se puede encontrar here .
Desde Evans DDD:
Un AGREGADO es un grupo de objetos asociados que tratamos como una unidad con el propósito de realizar cambios en los datos. Cada AGREGADO tiene una raíz y un límite. El límite define lo que está dentro del AGREGADO. La raíz es una ENTIDAD específica y única contenida en el AGREGADO.
Y:
La raíz es el único miembro de AGREGADO que los objetos externos pueden contener referencias a [.]
Esto significa que las raíces agregadas son los únicos objetos que se pueden cargar desde un repositorio.
Un ejemplo es un modelo que contiene una entidad de Customer y una entidad de Address . Nunca accederíamos a una entidad de Address directamente desde el modelo, ya que no tiene sentido sin el contexto de un Customer asociado. Por lo tanto, podríamos decir que el Customer y la Address juntos forman un agregado y que el Customer es una raíz agregada.
En Erlang no hay necesidad de diferenciar entre agregados, una vez que el agregado está compuesto por estructuras de datos dentro del estado, en lugar de la composición de OO. Vea un ejemplo: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london
En el contexto del patrón de repositorio, las raíces agregadas son los únicos objetos que el código de cliente carga desde el repositorio.
El repositorio encapsula el acceso a los objetos secundarios: desde la perspectiva de la persona que llama, los carga automáticamente, al mismo tiempo que se carga la raíz o cuando realmente se necesitan (como ocurre con la carga diferida).
Por ejemplo, es posible que tenga un objeto Order que encapsule las operaciones en varios objetos LineItem . Su código de cliente nunca cargaría los objetos LineItem directamente, solo la Order que los contiene, que sería la raíz agregada para esa parte de su dominio.
Imagine que tiene una entidad informática, esta entidad tampoco puede vivir sin su entidad de software y su entidad de hardware. Estos forman el agregado de la Computer , el mini-ecosistema para la parte de computadora del dominio.
La raíz agregada es la entidad nodular dentro del agregado (en nuestro caso Computer ), es una práctica común que su repositorio solo funcione con las entidades que son raíces agregadas, y esta entidad es responsable de inicializar las otras entidades.
Considere la raíz agregada como un punto de entrada a un agregado.
En el código C #:
public class Computer : IEntity, IAggregateRoot
{
public Hardware Hardware { get; set; }
public Software Software { get; set; }
}
public class Hardware : IEntity { }
public class Software : IValueObject { }
public class Repository<T> : IRepository<T> where T : IAggregateRoot {}
Tenga en cuenta que es probable que Hardware también sea un ValueObject (no tenga identidad propia), considérelo solo como un ejemplo.
La raíz agregada es un nombre complejo para una idea simple.
Idea general
Diagrama de clase bien diseñado encapsula sus partes internas. El punto a través del cual accede a esta estructura se llama aggregate root .
Las root.doSomethingWhichHasBusinessMeaning() internas de su solución pueden ser muy complicadas, pero el usuario de esta jerarquía solo usará root.doSomethingWhichHasBusinessMeaning() .
Ejemplo
Comprueba esta simple jerarquía de clases.
¿Cómo quieres montar tu coche? Elija mejor api
Opción A (simplemente funciona de alguna manera):
car.ride();
Opción B (el usuario tiene acceso a las clases internas):
if(car.getTires().getUsageLevel()< Car.ACCEPTABLE_TIRE_USAGE)
for (Wheel w: car:getWheels()){
w.spin();
}
}
Si crees que la opción A es mejor entonces felicidades. Usted obtiene la razón principal detrás de aggregate root .
La raíz agregada encapsula múltiples clases. Puede manipular toda la jerarquía solo a través del objeto principal.
Si sigue un enfoque de base de datos primero, la raíz agregada suele ser la tabla en el lado 1 de una relación de 1 a muchos.
El ejemplo más común de ser una persona. Cada persona tiene muchas direcciones, uno o más recibos de pago, facturas, entradas de CRM, etc. No siempre es así, pero sí lo es 9/10 veces.
Actualmente estamos trabajando en una plataforma de comercio electrónico, y básicamente tenemos dos raíces agregadas:
- Clientes
- Vendedores
Los clientes suministran información de contacto, les asignamos transacciones, las transacciones obtienen artículos de línea, etc.
Los vendedores venden productos, tienen personas de contacto, sobre nosotros páginas, ofertas especiales, etc.
Estos son atendidos por el cliente y el repositorio del vendedor, respectivamente.
Agregado significa colección de algo.
root es como el nodo superior del árbol, desde donde podemos acceder a todo como el nodo <html> en el documento de la página web.
Analogía de blog, un usuario puede tener muchas publicaciones y cada publicación puede tener muchos comentarios. así que si buscamos a cualquier usuario, entonces puede actuar como root para acceder a todas las publicaciones relacionadas y comentarios adicionales de esas publicaciones. Todos estos juntos se dice que son de colección o agregados