domain driven design - significado - ¿Cómo se manejan las asociaciones entre los agregados en DDD?
domain driven design pdf (3)
Todavía estoy pensando en DDD, y uno de los obstáculos que he encontrado es en cómo manejar asociaciones entre agregados separados. Digamos que tengo un agregado encapsulando Clientes y otros Envíos encapsulados.
Por razones comerciales, los envíos son sus propios agregados y, sin embargo, deben estar vinculados explícitamente a los Clientes. ¿Mi entidad de dominio del cliente debe tener una lista de envíos? Si es así, ¿cómo llené esta lista en el nivel del repositorio, dado que tendré un CustomerRepository y un ShipmentRepository (un repositorio por agregado)?
Estoy diciendo ''asociación'' en lugar de ''relación'' porque quiero enfatizar que esta es una decisión de dominio, no de infraestructura. Primero estoy diseñando el sistema desde el modelo.
Editar: Sé que no necesito modelar tablas directamente a los objetos, esa es la razón por la que estoy diseñando el modelo primero. En este punto, no me importa en absoluto la base de datos, solo las asociaciones entre estos dos agregados.
Creo que hay dos niveles de respuesta a esta pregunta. En un nivel, la pregunta es cómo puedo poblar la relación entre el cliente y el envío. Me gusta mucho la semántica de "relleno" donde tu repositorio de envío puede tener un fillOrders (Lista de clientes, ....).
El otro nivel es "cómo manejo los modelos de dominio desnormalizados que son parte de DDD". Y "Cliente" es probablemente el mejor ejemplo de todos ellos, porque simplemente aparece en muchos contextos diferentes; casi todos sus procesos tienen clientes en ellos y el contexto del cliente suele ser extremadamente variado. Al máximo la mitad del tiempo, estás interesado en los "pedidos". Si mi comprensión del dominio era perfecta al comenzar, nunca haría un concepto de dominio del cliente. Pero no lo es, así que siempre termino haciendo que el cliente se oponga. Todavía recuerdo el proyecto en el que después de 3 años sentí que era capaz de crear el modelo de dominio "Cliente" adecuado. Buscaría conceptos alternativos y más detallados que también representen al cliente; PotentialCustomer, OrderingCustomer, CustomerWithOrders y probablemente algunos otros; lo siento, los nombres no son mejores. Necesitaré más tiempo para eso;)
No hay razón para que su ShipmentRepository no pueda agregar datos de clientes en sus modelos de envío. Los repositorios no tienen que tener una asignación de 1 a 1 con tablas.
Tengo varios repositorios que combinan varias tablas en un solo modelo de dominio.
El envío tiene una relación de muchos a uno con el cliente. Si está buscando los envíos de un cliente, agregue una consulta a su repositorio de envío que tome un parámetro de cliente.
En general, no creo asociaciones entre entidades cuando las muchas partes no están limitadas.