domain-driven-design - 聚合根 : State Change or fail with Exception or . ..?

标签 domain-driven-design state event-sourcing aggregateroot saga

聚合根用于控制状态更改 - 当前允许的和不允许的。如果允许状态转换,则继续。如果没有,您会抛出一个异常,解释为什么不允许这样做。

但是如果 状态变化不会发生 因为它是 已处于请求状态 ?

例如,如果您有一个 Approve您的聚合根上的方法,当它被调用时,状态已经被批准了?

  • 应该是 抛出异常 拉“ XYZ 已经被批准 ”?
  • 或者应该是默默无视 ?
  • 还是应该状态变化再次“发出信号” (事件溯源,下一段)?

  • 就我而言,我使用事件源,因此如果发生状态更改,则会发出一个事件。在我的事件流中没有真正的状态变化的事件对我来说并不“干净”,因为我想确信这些事件实际上是由于状态变化的 Action 而产生的。

    有经验法则吗?

    编辑:
    在所描述的情况下,批准已批准的元素不会真正受到伤害。所以倾向于这种方式(谢谢@Eben Roux,@guillaume31)。

    但是,让我们为其添加更多趣味(问题背后的实际问题):

    认为:
  • 消息总线
  • 异步命令/事件处理
  • 流程经理

  • 如果 流程经理 (aka saga) 发出命令 (async) 并想知道命令是否成功?我认为如果流程经理不必关心这个实现细节,它会减少心理负担/错误来源。

    我看到了 3 种处理方式:
  • 有一个 “ID 为 ABC 的命令成功/失败”消息 送上巴士
    进程管理器等待该消息而不是事件
  • 制作 命令执行同步
    如果进程管理器没有遇到异常,一切都很好,继续
  • 介绍新事件ApprovalDeclined { WasAlreadyApproved = true }
    此外,流程管理器等待此事件 - 赤纬是总历史的一部分,也许是优势,也许永远不需要...

  • 我知道:“这取决于”
    但是你能想到任何其他(更优雅/更简单/不同)的解决方案吗?您最喜欢的“与流程管理器兼容”的处理这个问题的方式是什么?

    最佳答案

    我认为这不会有经验法则。

    消息幂等性当然是一件好事,所以简单地忽略消息/状态变化可能是要走的路。

    我不会再次发出信号,因为没有效果。

    关于domain-driven-design - 聚合根 : State Change or fail with Exception or . ..?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26115194/

    相关文章:

    variables - 在 View 之间传递变量 SwiftUI

    .net - EventStore 订阅一个类别的流

    android - 保持应用程序处于运行状态以接收来自 Urban Airship 的推送

    design-patterns - 如果发生任何故障,Saga 模式是否能够帮助逆转支出?

    azure - 如何将事件可靠地存储到 Azure CosmosDB 并仅一次调度到事件网格

    dns - 实体观点

    domain-driven-design - 如何在存储库之间进行通信

    c# - 如何使用 DDD/CQRS 编写功能

    domain-driven-design - 在 DDD/分层架构中存储常量的位置

    asp.net - 我是否必须在 ASP.NET 中使用 Viewstate