【问题标题】:When a line item is removed from an order, is it ok to have a transaction across bounded contexts?当从订单中删除订单项时,是否可以跨有界上下文进行交易?
【发布时间】:2011-06-27 19:50:11
【问题描述】:

在我的领域中,我有 2 个与此问题相关的有界上下文:

  1. 采购 - 客户订购服务的地方
  2. 履行 - 将服务分配给供应商以完成

要求客户在整个订单生命周期的任何给定时间都可以编辑订单。

如果客户从订单中删除了一项服务(即在采购环境中),如果该服务已分配给供应商执行(但尚未执行),则该服务也必须在履行过程中删除语境。

这里有几个选项,我想听听社区的意见:

  1. 我的上下文有误,因为这会创建跨上下文事务。
  2. 这里我可能不需要事务一致性。当然,这是由业务利益相关者决定的,这引出了两个问题:实施选项是什么?我如何向业务利益相关者提出这个问题?
  3. 这是可以接受的违反“无跨上下文事务”规则的行为。

编辑

这一切都发生在一个进程中,因此中间事务失败的可能性非常低。

【问题讨论】:

    标签: domain-driven-design bounded-contexts


    【解决方案1】:

    这是要问您的利益相关者的问题,回复:订单始终可编辑 - 订单在完成后可编辑意味着什么?

    【讨论】:

    • 我没有说清楚。该服务尚未完成。刚刚与供应商进行了安排,供应商需要更新(即发布新的工作说明)以反映已删除的服务。
    • 我更新了问题的文本以反映我上面的评论。谢谢,Udi!
    【解决方案2】:

    为什么有必要在编辑订单时影响履行服务?

    在我看来,这跨越了有界的上下文。订单在编辑时不应离开其域,除非有充分的理由。为什么订单信息会在完成之前传播到履行服务?

    基于我对您的领域显然非常有限的了解,我认为您会先完成订单,然后将创建事件发送到服务总线,由履行服务接收。因此,不会发生跨上下文的事务。

    【讨论】:

    • 在实际执行服务之前,可以编辑订单。我知道这很奇怪,但这是域的要求。这些订单很复杂,并且正在添加东西(并且可能会被删除,这是我主要关心的问题,因为执行客户想要取消的服务会花费利益相关者的钱)。
    • 我认为在您的场景中,让事物在事务中运行是不可能的,因为在一段时间内会发生一些操作,包括取消操作(添加订单行,再次删除它)。我认为正确实现这一点的唯一方法是通过每个操作的事件(OrderLineAdded、OrderLineRemoved)和相应的事件处理程序。恐怕这意味着补偿而不是交易。只是我的 2 美分。
    猜你喜欢
    • 2011-04-15
    • 1970-01-01
    • 2023-03-15
    • 2012-09-16
    • 2021-12-02
    • 2018-05-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多