Domain driven design DDD-有界上下文共享/通信

我正在尝试在允许客人购买的应用程序中使用一些DDD方法。虽然看起来很简单，但我还是有点困惑，想听听你的DDD建议

该应用程序具有多个有界上下文，我们正在查看其中的3个：

客户（客户在此处管理其用户设置、身份验证以及管理员可能创建的用户）

销售（订单）

计费（向客户收取一次性付款和订阅费）

用户故事： 作为一名客人，我想订购产品来做点什么

这是一张表格，结账时他/她将被要求提供电子邮件和密码。我们需要在此步骤中创建帐户，但基于业务逻辑，这适合于销售上下文-客户下订单。我们实际上需要做一些简单的步骤：

创建具有活动状态的用户

商店账单明细

创建订单

稍后向用户收费（由账单处理的事件）

---

这里的困惑在于它需要先创建一个用户。在客户中创建它看起来更自然，但可能是错误的？用户不能以任何其他方式注册-只能通过下订单，但管理员可以手动创建用户。基于不同的系统事件（来自不同的上下文），客户上下文可能会根据放置在客户域中的特殊逻辑更改用户状态。是否有任何安全的方法可以在不同的上下文之间共享此用户状态逻辑（在销售中创建用户时，我们需要该状态枚举类）？下订单的逻辑看起来正常吗？如果您认为这个方法是错误的，请推荐另一种方法好吗？

状态是DDD最差的状态。包括一个状态字段是1）懒惰的，但2）非常方便。是的，其中一个设计权衡

当您分配状态或读取状态时，您忽略或升华了域的重要业务逻辑和结构。当“状态”更改时，您的域中可能会发生一些非常重要的更改。。。不仅仅是更改状态属性

抛出<强>状态<强>，而应考虑一些概念：临时购物者或访客（没有购买，浏览产品），PotentialNewShopper（有人在他们的篮子里加上你以前从未见过的东西），和你平常的客户（应该根据他们当前的活动细分）。 使用此模型，您可以将行为直接附加到这些对象中的每一个，并且“状态”本身将升华为更丰富的DDD模型。一个常见的DDD错误是没有为某些静态/非时态对象（例如，人）创建具有事务重要性的对象（例如，潜在的购物者角色）

从这里你可以决定你需要一些有界的上下文；可能是潜在客户和现有客户。在每个域中，域转换集都是不同的，可以封装而不是外部化

所以…

这样看来，你有一个客户BC和一个可能的客户BC。由于后者是独立的，所以您可以安全地在后者中执行您需要执行的操作

哦，但这可能会影响账单！还有点菜

对。这可能意味着新的BC或这些BC中的新对象，如临时付款和未经验证的订单。我现在有点吐痰了

我的观点是，您有可以在状态之间转换的事件，而不是对这些状态进行编码，因此您可以附加所需的行为，并根据需要将其持久化到某个物理存储中，该物理存储可能以适合您的DDD的方式进行分区

完成所有这些工作意味着不共享不安全状态，而只共享相关对象的安全投影

---

简单而有趣地开始实现，开发人员不愿意存储“临时”状态。“临时”状态是可以存储的，并且在您对没有该cruddystatus字段的域进行建模时是必需的

你可能应该先问问自己，你是否正确理解了有界上下文

在我看来，您有以下BCs

• 身份和用户
• 销售和计费

考虑一下：同一个人在第一个上下文中是

用户

，但在后一个上下文中是

客户

。所以你对同一个真实世界实体有两种观点，这表明你有两个有界的上下文，其中这个实体意味着不同的东西

您的bcs听起来更像是

销售和计费环境中的模块

如果您同意，则可以简化问题的控制流，其中在一个上下文中创建实体，并通过事件将创建传播到另一个上下文中。因此，最初的请求可以由
销售人员
bc处理，而来宾用户处理将传播到
身份