¿Cómo debería diseñar un agregado DDD con una invariante basada en información de múltiples agregados?
Soy nuevo en Diseño Dirigido por Dominio y estoy completamente bloqueado con un problema de modelado. Aquí hay una captura de pantalla del evento storming a nivel de diseño de una función simple con solo una invariante: imagen de evento storming.
Supongamos que no se permite la consistencia eventual para la condición del certificado y es absolutamente crucial cumplir con esta condición de inmediato para procesar un pedido. En este caso, para verificar mi invariante de certificado, necesito tener acceso a:
- temporada del pedido
- país del proveedor
- temporada a partir de la cual se verifican los certificados para un país específico
- certificados del proveedor y si están aceptados y actualizados
Inicialmente intenté dividir mi aplicación en múltiples contextos delimitados y para mí esa información pertenece a diferentes contextos delimitados. ¿Debería tener entonces todos estos datos necesarios (lista de arriba) en un agregado para garantizar la consistencia y tenerlo bastante grande o tal vez hay alguna otra solución? ¿Tal vez todo mi razonamiento está mal y no tiene mucho sentido? ¿Tal vez los límites de los contextos delimitados están mal debido a la necesidad de acceder a datos de otros contextos (no siendo autónomos)? ¿Tal vez un servicio de dominio podría ser una solución? Estaría muy agradecido por cualquier ayuda porque estoy bastante confundido con estos temas de ddd :/
davy.ai
Como experto en tecnología de la información especializado en modelado de diseño orientado al dominio, agregados y contextos delimitados, sugeriría el siguiente enfoque para manejar el problema de modelado en este escenario:
Definir el Contexto Delimitado: Con base en el dominio central identificado, podemos definir el contexto delimitado. En este caso, parece que podría haber dos contextos delimitados, uno para el dominio de “Órdenes” y otro para el dominio de “Certificados”.
Definir los Agregados: Dentro de cada contexto delimitado, debemos definir los agregados. En el contexto delimitado de “Certificados”, la entidad “Certificado” podría ser el agregado. Dentro del contexto delimitado de “Órdenes”, podríamos tener la entidad “Orden” como el agregado.
Definir los Invariantes: Cualquier objeto del dominio tiene ciertos invariantes que deben cumplirse para considerarlo en un estado válido. En este caso, el invariante principal es la condición del certificado, que debe cumplirse de inmediato para procesar una orden. Definiremos este invariante dentro del agregado de “Certificados”.
Definir las Relaciones: Dado que necesitamos información tanto del contexto delimitado de “Órdenes” como del contexto delimitado de “Certificados”, debemos definir las relaciones entre ambos. La entidad “Orden” debería tener una referencia a la entidad “Certificado”, que se puede utilizar para verificar la condición del certificado.
Utilizar Servicios de Dominio: En casos en los que necesitamos realizar operaciones que abarquen varios agregados/contextos delimitados, podemos utilizar servicios de dominio. En este caso, podemos definir un servicio de dominio que tome las entradas necesarias (país del proveedor, temporada de la orden, etc.) y realice las verificaciones necesarias en el certificado.
En resumen, debemos enfocarnos en el dominio central, definir los contextos delimitados, agregados, invariantes y relaciones. Si es necesario, podemos utilizar servicios de dominio para realizar operaciones que abarquen varios agregados/contextos delimitados.