DDD中限界上下文间实体Guid标识符的管理疑问

针对你提出的产品在销售、物流、库存三个上下文的ID管理问题，分情况给出具体方案：

一、是否共享同一个Guid？ #

这取决于各上下文的Product是否属于同一核心实体的不同视图：

• 如果三个上下文的Product本质是同一个产品的不同业务视角（比如销售侧关注定价、描述，物流侧关注重量、尺寸，库存侧关注存量、批次），可以共享同一个Guid。这种方式能简化跨上下文的识别成本，毕竟它们指向的是业务上的同一个产品。
• 如果各上下文的Product是完全独立的领域概念（比如物流侧的"产品"可能是打包后的运输单元，和销售侧的单个商品不是一一对应），那必须使用不同的Guid。因为此时它们已经是不同的领域实体，共享ID会混淆边界，导致上下文耦合。

二、不同ID下如何关联上下文的产品？ #

如果选择为各上下文分配独立Guid，可以通过两种方式建立关联：

• 维护映射关系表：在上下文边界（比如集成层或共享基础设施）维护一张映射表，记录SalesProductId、ShippingProductId、InventoryProductId与全局业务标识的对应关系。当需要跨上下文查询时，先通过当前上下文的ID查到全局标识，再用全局标识找到其他上下文的对应ID。
• 携带业务标识传递：在上下文间交互时（比如销售下单后通知物流备货），除了传递当前上下文的实体ID，还要带上产品的业务唯一标识（比如SKU、产品编码）。物流上下文接收后，用业务标识找到自己的Product实体，完成关联。

三、不同ID下跨上下文识别同一产品？ #

核心是依赖业务层面的唯一标识，而不是领域实体的Guid：

• 定义一个全局认可的业务标识（比如SKU、商品条形码、官方产品编号），这个标识在所有上下文里是唯一且不变的。每个上下文的Product实体都要存储这个业务标识。
• 跨上下文交互时，以业务标识为核心依据，而不是各自的Guid。比如库存系统需要确认销售订单里的产品存量，就通过订单里的SKU去库存系统查询，而不是用销售侧的Guid。
• 可以通过领域事件同步关联：当销售上下文创建Product时，发布ProductCreated事件，携带业务标识；物流、库存上下文订阅该事件，创建自己的Product实体并存储相同的业务标识，后续就可以通过这个标识实现跨上下文识别。

内容的提问来源于stack exchange，提问作者Kasun Jalitha