2

我目前正在研究这个用例：

  1. 将预算分配给组织单位
  2. 迈克使用预算订购了一件商品
  3. Jane 同意此订单，验证它。此操作会触发这些后果：
    1. 检查预算余额，看看我们是否可以接受这个订单：如果失败，通知简。
    2. 预算减少到订单金额
    3. 订单状态从 WAITING_VALIDATION 更改为 VALIDATED
    4. 向 Jane 显示一条成功消息

其他用例信息：

  • 对于我们的用户来说，从 3.1 到 3.4 的步骤必须是实时的。Jane 单击按钮并等待答案：OK 或 NOT OK AND订单状态已验证

我在想：

  • 预算是一个有界的上下文。
  • 排序是另一个有界上下文。
  • 验证步骤将更改 2 个聚合根，这似乎是错误的。并添加耦合。如果我们需要同时更新另一个聚合根（第 3 步，例如为商品创建会计折旧分录）。
  • 为了实时，我们可以使用 XA 事务（例如 SQL + 消息传递），但我想避免它（此外，我当前的技术堆栈不允许我使用 XA 事务）。

似乎我们可以使用最终一致性来实现这种用例： - 订购服务要求预算服务处理 processOrder 命令（通过消息传递或 REST）：此时订购服务正在等待预算服务。- 预算服务处理命令（在本地事务中）并将 OK / NOK 发送给调用者 - 预算服务还发送 OrderInBudgetProcessed 事件。- Ordering Service 实时接收 OK/NOK 并通知 Jane（但此时订单状态没有改变） - Ordering Service 处理 OrderInBudgetProcessed 并在本地事务中更新订单状态。

我认为这可以工作。但是我有一些问题：

  • 在订单状态未更新期间，Jane 无法打印订单以将其发送给供应商。
  • 在订单状态未更新期间，我们可以想象 Mike 想要取消订单。状态仍为 WAITING，因此允许“取消”操作。我们必须向 BudgetService 询问订单已经处理吗？如果是，那么我们必须使用命令询问所有服务的状态。我们可以使用 saga 或 coordinator 之类的东西吗？
  • 采取补偿行动似乎需要做很多工作......

一些问题 ：

  • “订单验证” - 由 2 个步骤组成 - 主要由预算上下文或订单上下文处理？（在我看来，主要事件是预算减少，所以我在考虑预算背景）。对你来说似乎有逻辑？
  • 您如何看待这种用例？太复杂了？
  • 你怎么处理这个？
  • 我想同时拥有一个干净的代码（避免更新/同步同一事务中的所有对象的服务）和一个域用户（迈克/简）满意。

请纠正我哪里错了:)

期待您的回音。

弗朗索瓦

4

1 回答 1

2

我曾经遇到过类似的情况，方法最终是这样的：

两个有界上下文：库存和订购

当订单需要满仓时，排序上下文接受该命令，它将订单从 WAIT_FULLFILL 更新为 FULLFILLING 并发出 OrderFullfillingRequiredEvent。

库存上下文订阅此事件并进行库存更新，然后发出带有订单跟踪 ID 的 InventoryUpdatedEvent。

排序上下文订阅后一个事件并将订单从 FULLFILLING 更新为 FULLFILLED。

如果有人想在此期间取消订单，它将被拒绝，因为状态现在是 FULLFILLING，这表明订单正在等待响应。

相当于你的用例，我认为它会添加一个中间状态WAITING_VALIDATION-->VALIDATING-->VALIDATED。

并且仍然需要一些补偿，因为 InventoryUpdatedEvent 可能永远不会到来。最烦人的问题是在 ui 方面，也许您需要轮询后端以使其看起来像实时。

于 2014-10-12T02:19:09.440 回答