Diseñar raíz agregada correctamente

Tengo algunos problemas para diseñar la raíz agregada. Así es como lo veo en mi mente :)Diseñar raíz agregada correctamente

Store (the aggregate root) 
-> Sales - A store create a sale every day 
-> Zones - A store is divided into zones 
    -> Styles - A zone has x number of styles 
     --> Colors - A style has x number of colors 
    etc..

Ahora, en base a esto mi raíz de agregado sería la tienda. Sin embargo, si ahora fuera a crear un Repositorio, ¿se vería algo como esto?

public class StoreRepository() 
{ 
    Store GetById() {...} 
    StoreZone GetZone() {...} 
    List<StoreZoneStyle> GetStylesByZone() {...} 
    List<Color> GetColorsByStyle() {...} 
}

¿Es esa una buena manera de continuar? No hace falta decir que soy nuevo en DDD.

Fuente

2009-10-28 vikasde

Creo que necesita ver los límites agregados y las entidades como algo más que una simple jerarquía. Es probable que tengas un modelo más rico que eso.

La primera manera de saber si su agregado es correcto, es que puede ver cada una de las entidades que contiene y preguntar "¿Se debe acceder directamente a esto?" Si responde afirmativamente, es probable que esa entidad no forme parte del agregado.

Sin saber más acerca de su dominio, podría suponer que Store es realmente un agregado. Las ventas, por otro lado, son más complejas. Sí, las ventas se producen en una tienda, pero ¿necesita buscar una venta de forma independiente? Si los necesita fuera del alcance de simplemente trabajar con una tienda, las ventas probablemente estén fuera de ese agregado.

Imagino que tanto los Estilos como los Colores son inmutables y repetibles, por lo que probablemente sean Objetos de Valor en este caso. ¿Son las zonas exclusivas de una tienda, o varían?

Personalmente, encuentro valioso identificar todos los artículos del dominio en papel (o pizarra). Pasaré por una fase de descubrimiento con la parte interesada y simplemente los sacaré de allí. Luego, use estas palabras como líderes en la conversación, tratando de entender cómo se relacionan. Si entreviste a la parte interesada lo suficientemente bien, la descripción que brinda definirá la mayoría de lo que está buscando.

No es para vencer a un caballo muerto, pero el libro de Evans definitivamente vale la pena obtener/leer. Es un poco seco, pero muy perspicaz. Para un jumpstart rápido, puede leer el free book en InfoQ que es básicamente un resumen del libro de Evans.

Fuente

2009-10-28 20:22:15

Sí, también me gustaría acceder a las ventas directamente, probablemente con solo pasar el StoreId. ¿Supongo que crearía un SaleRepository en ese caso? Las zonas varían según la tienda.Cada tienda puede tener una cantidad x separada de zonas. ¿Crearía un ZoneRepository aquí también? Ordené el libro de Evans, sin embargo, comenzaría a investigar mi dominio. Por favor, avíseme si necesita cualquier otra información. Mientras más conocimiento pueda obtener, mejor entenderé DDD. Gracias de nuevo. – vikasde

Los límites agregados son probablemente lo más difícil en DDD, en mi opinión. Si está buscando tener que pasar un identificador de tienda en un repositorio de ventas propuesto, hay dos posibilidades que son inmediatas. En primer lugar, las Ventas podrían ser parte del agregado de la Tienda que usted mencionó. El otro podría ser que una Tienda podría ser parte de un agregado de Ventas. La única forma en que realmente serían agregados sería si necesita acceder de manera independiente y sin que requieran el conocimiento directo del otro. Tenga en cuenta que no le impide ... –

... mantener una referencia a otra raíz agregada. Por ejemplo, si determina que tanto Tienda como Ventas son raíces agregadas, nada impide que una Venta tenga una referencia a un Identificador de tienda, que luego puede usar para llamar al Depósito de Tienda para obtener la Tienda cuando la necesite. En cuanto a las Zonas, existe una relación definida con la Tienda. Esto refuerza el caso de que Store * es * una raíz agregada y Zone es una entidad (ya que no son necesariamente inmutables en el contexto que describió). Entonces, ahora mismo, estamos seguros de que Store es un agregado que contiene Zonas ... –

Parece que "Tienda" no es una raíz agregada porque no quiere ocultar toda la funcionalidad para "Zonas", "Ventas", etc. detrás del objeto "Almacenar". De esa manera, el objeto "Tienda" puede estar muy hinchado.

"Tienda", "Zona" y "Venta" podrían tener su propio repositorio.

Fuente

2009-10-28 20:17:50

¿No sería abultado tener un repositorio para cada objeto? Después de todo, todos están relacionados con la tienda, ¿correcto? – vikasde

Si hay un repositorio para cada objeto, no está hinchado. Son objetos más pequeños y comprensibles (Principio responsable único). Si tiene una clase base para el repositorio (Repository ), es aún menos la escritura de código. De esa manera, probablemente solo tenga que escribir consultas especiales para esas entidades. –

Las raíces agregadas son límites de consistencia para transacciones, distribuciones y concurrencia (Eric Evans via Gojko Adzic).

Cuando dos personas modifican diferentes zonas en la misma tienda, ¿debería causar un conflicto de simultaneidad? Si no, entonces quizás las Zonas deberían ser su propia Raíz Agregada separada de las Tiendas.

Fuente

2011-02-12 04:14:30

Diseñar raíz agregada correctamente

Respuesta

Cuestiones relacionadas