Cómo modelar el orden de clasificación de muchos a uno en dos raíces agregadas

Question

Tome el dominio propuesto en Diseño agregado efectivo de un Producto que tiene múltiples Lanzamientos.En este artículo, Vaughn llega a la conclusión de que tanto el Producto como el Lanzamiento deben ser cada uno sus propias raíces agregadas.

Ahora supongamos que agregamos una característica

• Como administrador de lanzamientos me gustaria poder ordenar lanzamientos de modo que Puedo crear cronogramas para implementar epopeyas más grandes para nuestros usuarios.

No soy un PM con una necesidad específica, pero parece razonable que quieran tener la capacidad de ordenar lanzamientos en la interfaz de usuario.

No estoy exactamente seguro de cómo debería funcionar esto.Es natural que cada versión tenga una propiedad de orden, pero reordenar implicaría cambiar múltiples agregados en la misma transacción.Por otro lado, si esa información se almacena en el agregado del Producto, debe tener un método como product.setRelaseOrder(ReleaseId[]) lo que parece un dato extraño para almacenar en un lugar completamente diferente al de las versiones.Peor aún, agregar una versión nuevamente implicaría modificaciones en dos agregados diferentes.qué más podemos hacer?ProductReleaseSortOrder puede ser su propio agregado, ¡pero eso suena completamente absurdo!

¿Entonces lo que hay que hacer?Por el momento todavía me inclino por la opción dejar que el producto lo administre, pero ¿qué es correcto aquí?

Answer 1

Entonces, el producto y la liberación son ambos ARS.La versión tiene una asociación al producto a través de AgregateID.¿Quieres obtener la lista de todas las versiones para un producto dado ordenado por algo?

Dado que el pedido es un atributo de agregado, entonces debe establecerse en el producto, pero las versiones también son ARS y no debe acceder al repositorio de liberación en el producto AR (cada AR debe tener su propio repositorio).

Simplemente haría un servicio de comunicados que ocupa el parámetro PRODUCTUS y PEDIDO y llame a la llamada. Llamado.

¡También pensaría en separar los contextos, tal vez el modelo para la presentación de la liberación debe estar en otro contexto?En el ejemplo, AR ARTTRELASES DE PRODUCTOS QUE SE UTILIZARÍA SOLAMENTE PARA CONSEGUIR.

Answer 2

He descubierto que, de hecho, es mejor crear un nuevo raíz agregada (por ejemplo, ProductReleaseSorting como se sugiere) para cada propósito individual de clasificación y/o pedido.Esto es porque releaseOrder claramente no es en realidad una propiedad del Product, es decir, algo que tiene un significado en un producto por sí solo.Más bien, en realidad es una propiedad de una "vista" sobre un recopilación de productos, y esta visión debería modelarse por sí sola.

La razón por la que tiendo a introducir una nueva raíz agregada para cada vista individual de una colección de artículos queda clara si piensa en lo que sucedería si introdujera pedidos adicionales en el futuro, digamos un "orden de marketing", o varios gerentes de producto. quieren mantener sus propios pedidos, etc.Aquí se ve fácilmente que "orden de comercialización" y "orden de liberación" son dos conceptos diferentes que deben tratarse de forma independiente, y si varias personas quieren pedir los productos con la misma clave, pero utilizando diferentes pedidos, necesitará "orden individual". vistas por persona".Además, podría ser que existan múltiples criterios de orden que a uno le gustaría tener en cuenta al ordenar (un ejemplo de este último sería (en un contexto diferente) ruta más rápida vs.ruta más corta), todo lo cual depende de la vista que tenga de la colección y no de las propiedades individuales de sus elementos.

Si ahora maneja la clasificación del Gerente de Producto en un ProductReleaseSorting agregado, tu

1. tener una única fuente de soporte veraz para el pedido (el AR),
2. el ProductReleaseSorting AR puede imponer restricciones como que no hay dos productos que tengan el mismo número de pedido y usted
3. No se enfrente al problema de tener que actualizar varios AR en una sola transacción al cambiar el pedido.

Tenga en cuenta que su ProductReleaseSorting Lo más probable es que el agregado tenga una identidad única ("Singleton") en su dominio, es decir, todos los gerentes de producto comparten la misma clasificación.Sin embargo, si todos los miembros del equipo quisieran tener su propio ProductReleaseSorting, es trivial apoyar esto dando la ProductReleaseSorting una identificación correspondiente.De manera similar, una versión más genérica ProductSorting se puede obtener mediante una ID por equipo (marketing vs.gestión de productos) desde el repositorio.Todo esto es fácil con una raíz agregada nueva y separada para fines de ordenación, pero difícil si agrega propiedades a los elementos/entidades subyacentes.