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.