Es posible que desee mostrar el nivel de inventario en la página web, o puede que desee mostrar el número de edición del inventario en stock (imagine que su inventario es libros, revistas, etc.). Esta información proviene del dominio de inventario.
Lo principal a tener en cuenta en este momento es que está hablando de una vista, lo que significa que es aceptable usar datos obsoletos.
Dicho esto, no necesita interactuar con los agregados (que son responsables de evitar que los cambios infrinjan la invariante comercial), sino con una representación de una copia reciente del estado del agregado.
Entonces, lo que normalmente esperaría es una consulta ejecutada en el Catálogo de productos, y otra ejecución en el Inventario, y algo para componer los dos en el DTO que necesita para admitir la vista.
¿Cargar el dominio del producto y el agregado del dominio de inventario?
Entonces eso está cerca . No necesitamos cargar los agregados, porque no vamos a cambiar nada. Pero necesitamos su estado; para que podamos cargar eso. Dicho esto, normalmente esperaría que los dos dominios se ejecuten en diferentes procesos. Por lo tanto, estaríamos llamando a ambos, no cargando ambos.
¿Mantendría algunas propiedades en su entidad de dominio de Producto para el número en stock y la edición en stock, y luego usaría Eventos de dominio para actualizarlos cuando se actualice la entidad de Inventario?
"No cruce las corrientes. Sería malo".
Uso de eventos para coordinar información en contextos de dominio: gran idea. Empujar conceptos que pertenecen a un dominio en otro: opuesto a una gran idea, excepto más.
Desea mantener limpios los dominios. Las aplicaciones que interactúan con los dominios, no es tan importante. Entonces, por ejemplo, es razonable que la aplicación Inventario llame a un servicio en la aplicación del producto para consultar algunos conceptos específicos del producto para agregar a una vista. O viceversa.
No sé de ninguna razón por la que una sola aplicación deba restringirse a un solo dominio. Mientras haya una sola fuente de verdad, puede distribuir las transacciones de la forma que desee.
Pero solo para pensar esto, en el ejemplo anterior, terminaríamos con potencialmente 2 tablas de base de datos para el catálogo de productos y el inventario de productos. Ahora, ¿usamos el mismo identificador en estos ya que es el mismo producto?
Esa sería la manera fácil. En términos más amplios, usa el mismo identificador porque la entidad del mundo real es la misma; los dos contextos limitados diferentes modelan esa entidad de manera diferente, pero el modelo no es la entidad del mundo real.
Cuando eso no funciona, necesitará alguna consulta para cerrar la brecha. Creo que la variación más común de esto es que la entidad más nueva conserva la identificación de la entidad más antigua. Verá esto también dentro de un BC: los solicitantes, una vez aprobados, se convierten en clientes. Es un agregado diferente (el estado asociado con un cliente está sujeto a una invariante diferente a la del solicitante); así que si su capa de persistencia está usando secuencias de eventos, la secuencia para el nuevo agregado necesitará un identificador diferente. Entonces habrá un poco de estado en alguna parte que diga "este solicitante se convirtió en este cliente".
O, ¿podríamos usar 1 tabla y 1 fila de tabla para los datos y simplemente asignar los datos relevantes a las propiedades agregadas?
¡YIKES! No, no hagas eso. Está agregando contención de transacciones sin ninguna razón comercial para hacerlo.
Creo que su pregunta realmente requiere 2 conjuntos de opciones ortogonales:
¿Carga dos objetos y presenta sus datos juntos o carga 1 objeto que contiene todo lo que desea?
¿Utiliza agregados para mostrar cosas u otra cosa?
Si cree en el enfoque CQRS, resulta que los agregados pueden no ser la mejor opción para las lecturas. Cada vez que carga un agregado, ya sea para mostrar sus datos o modificarlo, agrega concurrencia y contención a su sistema. Además, los agregados son potencialmente más voluminosos y más lentos de cargar que si usa modelos de lectura ad-hoc diseñados para mostrar.
La solución a) de su Q parece estar sujeta a muchas de estas trampas. La opción b) puede ser válida, pero la usaría solo si
InventoryManagementse necesitan datos del BC para imponer invariantes al mutar elProductagregado. Es mejor si un agregado contiene todos los datos necesarios para verificar sus reglas de negocio después de la modificación, pero en el lado de lectura pueden ubicarse en cualquier lugar.Con respecto a los datos, una recomendación común es dar a los Contextos delimitados su propia base de datos (por razones de implementación y SoC). Probablemente tendrá que usar los mismos identificadores si desea hacer coincidir productos entre los dos BC.
Acerca de las interacciones entre BC, también puede consultar /programming/16713041/communicating-between-two-bounded-contexts-in-ddd
fuente
DDD está destinado a aplicaciones donde la lógica de negocios es compleja. "imprimir algo" no es una lógica empresarial compleja. En realidad no es una lógica de negocios en absoluto.
Si la lógica de negocios en un contexto necesita alguna información para manejar adecuadamente algún caso de uso, entonces esa información es parte de ese contexto. Por lo tanto, la idea de que un contexto limitado podría necesitar información disponible en un contexto limitado diferente no tiene sentido, porque el contexto limitado tiene toda la información que necesita.
fuente
Desde mi punto de vista, hay diferentes definiciones de "Producto": cada contexto limitante tiene su propia definición de "producto" -dominio:
Además de estos, agregaría un Contexto de límites de tienda adicional con su propia definición de producto (una combinación relevante de los dominios de producto de los otros Contextos de límite).
Una Tienda-Producto tendría "imagen y texto descriptivo" del contenido y disponibilidad del "Inventario" pero no "vendedor del producto" del inventario.
Este contexto de tienda adicional depende del contenido, inventario y precio del contexto de tienda.
fuente