我目前正在尝试了解DDD并且具有与以下类似的应用程序。我们假设我的购物车应用程序包含以下项目：
购物车（BC表示边界背景）
购物者（BC）
- 人（VO）
产品（BC）
- 产品（实体）
结算信息（BC）
- 地址（VO）
购物车（BC）
- 购物车实体
- LineItem（产品FK，地址VO）（实体）
- 购物者FK
- 账单FK
购物者访问网站并浏览要购买的产品。当购物者选择产品时，它会被添加到购物车中以及诸如购买数量等选项。当购物者准备结账时，点击链接查看购物车中的商品，他们可以在那里删除他们所做的任何商品不想。完成此步骤后，他们可以继续检查他们可以输入或选择信用卡的位置以及将购物车项目发送到的地址。该人的信用卡被收费，并且购物车和物品以队列形式显示给将履行订单的部门。
我认为这是正确的边界背景分解是否正确？
如果购物者和购物车之间存在一对多的关系，那么如何在两个聚合边界之间进行表示，或者这会违反规则？
考虑到它们处于不同的上下文中，购物者存储库是否应该调用购物车存储库来填充与购物者关联的购物车列表？
此外，由于订单项在Cart边界内存在似乎很自然，因此购物车存储库是否应对订单项上的crud操作负责，以及填充与购物车相关联的订单项列表？
答案 0 :(得分：0)
似乎您的有界上下文过于细化，并且您可能混合有界上下文（BC）与聚合根（AR）。
我不知道您的域名，但有界上下文不应该与聚合根对齐1对1，它们应该与子域对齐1对（在最佳方案中）。
聚合根是事务边界，负责保护真正的不变量，而有界上下文基本上是通过将问题空间用自己无处不在的语言分割成更小的上下文来避免术语重载的一种方法。
例如，购物有界上下文中的产品可能与发货中的产品不同上下文。例如。在购物上下文中，您可能对产品的评价分数感兴趣，但您不会在发货上下文中关注此问题。另一方面，在送货上下文中，您可能想知道如何安全地打包产品，但该信息在购物上下文中可能并不重要。
如果你没有将你的问题空间划分为有界的上下文，那么最终产品术语会被重载，而且具体的模型实现（例如Product类）会很大，很难掌握并且很难维护。
我不能告诉你应该是什么样的有限背景，但我对自己说错了很自信，我强烈建议你多阅读bounded contexts和aggregate roots。