DDD:试图理解边界上下文之间的功能
本文关键字：上下文 之间 功能 边界 DDD | 更新日期: 2023-09-27 18:30:04
我目前正在努力理解DDD，并有一个类似于以下内容的应用程序。假设我有一个购物车应用程序，其中包含以下项目：
购物车（BC表示边界上下文）
购物者（不列颠哥伦比亚省）
-人员（VO）
产品（BC）
-产品（实体）
计费信息（BC）
-地址（VO）
购物车（BC）
-购物车实体
-LineItem（产品FK，地址VO）（实体）
-购物者FK
-计费FK
购物者访问网站并浏览要购买的产品。当购物者选择产品时，它会与要购买的数量等选项一起添加到购物车中。当购物者准备结账时，单击链接查看购物车中的商品，在那里他们可以删除任何不想要的商品。完成此步骤后，他们可以继续结账，在那里他们可以输入或选择一张信用卡和一个地址来发送购物车项目。该人员的信用卡将被计费，购物车和项目将在队列中显示给将履行订单的部门。
假设这是正确的边界上下文分解，我是对的吗？
如果购物者和购物车之间存在一对多关系，那么这应该如何在两个聚合边界之间表示，或者这会违反规则吗？
考虑到它们处于不同的上下文中，购物者存储库是否应该调用购物车存储库来填充与购物者关联的购物车列表？
此外，由于行项目存在于Cart边界内似乎很自然，因此Cart存储库是否应负责行项目的crud操作以及填充与Cart相关联的行项目列表？
您的有界上下文似乎过于精细，并且您可能将有界上下文（BC）与聚合根（AR）混合。
我不知道你的域，但有界上下文不应该将1比1与聚合根对齐，它们应该将1对1与子域对齐（在最佳情况下）。
聚合根是事务边界，负责保护真正的不变量，而有界上下文基本上是通过使用其普遍存在的语言将问题空间划分为更小的上下文来避免术语过载的一种手段。
例如，购物有界上下文中的产品可能与运输上下文中的产品不同。例如，在Shopping上下文中，您可能对产品的评审分数感兴趣，但在Shipping下文中您不会关心这一点。另一方面，在Shipping上下文中，您可能想知道产品应该如何安全包装，但这些信息在Shopping下文中可能并不重要。
如果你不把你的问题空间划分成有界的上下文，你最终会发现Product这个术语被重载了，它的具体模型实现（例如Product类）将是巨大的，很难理解，也很难维护。
我不能告诉你什么应该是你的有界上下文，但我很有信心说它们是错误的，我强烈建议你多读一些关于有界上下文和聚合根的内容。