我还在纠结 DDD，我遇到的绊脚石之一是如何处理不同聚合之间的关联。假设我有一个封装客户的聚合和另一个封装发货的聚合。
出于业务原因，Shipments 是它们自己的集合，但它们需要明确地与客户相关联。我的客户域实体应该有一个货件清单吗？如果是这样，我如何在存储库级别填充此列表 - 假设我将有一个 CustomerRepository 和一个 ShipmentRepository（每个聚合一个 repo）？
我说的是“关联”而不是“关系”，因为我想强调这是一个领域决策，而不是基础设施决策——我首先从模型设计系统。
编辑：我知道我不需要将表直接建模为对象——这就是我首先设计模型的原因。在这一点上，我根本不关心数据库——只关心这两个聚合之间的关联。
您的 ShipmentRepository 没有理由无法将客户数据汇总到您的货件模型中。存储库不必与表进行一对一的映射。
我有几个存储库，它们将多个表组合成一个域模型。
我认为回答这个问题有两个层次。一方面，问题是我如何填充客户和发货之间的关系。我真的很喜欢“填充”语义，您的货件存储库可以有一个 fillOrders(List customers, ....)。
另一个层次是“我如何处理作为 DDD 一部分的非规范化域模型”。而“客户”可能是最好的例子，因为它只是出现在很多不同的上下文中；几乎您的所有流程中都有客户，而且客户的环境通常非常多样化。最多有一半时间您对“订单”感兴趣。如果我在开始时对领域的理解是完美的，我永远不会提出客户领域的概念。但事实并非如此，所以我总是最终制作 Customer 对象。我仍然记得3 年后我觉得我能够制作正确的“客户”域模型的项目。我会正在寻找也代表客户的替代和更详细的概念；PotentialCustomer、OrderingCustomer、CustomerWithOrders 可能还有其他一些；对不起，名字不是更好。我需要更多时间；）
Shipment 与 Customer 具有多对一的关系。如果您正在寻找客户的货件，请向您的货件存储库添加一个带有客户参数的查询。
一般来说，当多方不受限制时，我不会在实体之间创建一对一的关联。