事件溯源中Aggregate root方法是否应修改状态？技术问询

原始聚合根代码 #

class Account{

    val balance: BigDecimal = BigDecimal.ZERO

    fun apply(event: EntryRegisteredEvent){
        balance -= command.amount
    }

    fun registerNewDebitEntry(command: RegisterNewDebitEntryCommand): EntryRegisteredEvent {
        if(balance < command.amount)
            throw InsufficientBalanceException()

        balance -= command.amount

        return EntryRegisteredEvent.create(...)
    }
}

核心疑问 #

为何要在registerNewDebitEntry()方法中修改balance状态？该方法是否应仅检查不变量并生成事件，而将修改Aggregate root状态的职责仅交给apply()方法？这种职责分离是否合理？

优化后的代码（Edit 1） #

fun registerNewDebitEntry(command: RegisterNewDebitEntryCommand): EntryRegisteredEvent {
    if(balance < command.amount)
        throw InsufficientBalanceException()
    
    val event = EntryRegisteredEvent.create(...)
   
    apply(event)

    return event
}

后续疑问 #

但疑问仍在：此时我真的需要修改Aggregate root状态吗？

个人思考（Edit 2） #

我认为唯一的理由是在同一流程中需执行多个command的场景，但如果没有这种需求，我找不到修改AR状态的必要性。

解答 #

在Event Sourcing模式下，聚合根状态的修改必须通过apply事件来完成，这是核心原则，背后的原因和必要性如下：

1. 职责分离是正确的设计 #

Edit 1的优化方向完全正确：

• 命令方法（registerNewDebitEntry）：只负责业务规则校验（如余额充足性检查）、生成对应事件，不直接操作状态。这让命令方法聚焦于“业务决策”，而非“状态变更细节”。
• apply方法：是状态变更的唯一入口，所有能改变聚合根状态的逻辑都在这里实现。这样做能避免逻辑重复——比如最初代码里两处修改balance的逻辑，后续调整时很容易出现遗漏，而单一入口能彻底解决这个问题。

2. 必须修改内存状态的原因 #

哪怕当前没有多命令执行的场景，也必须在生成事件后立即调用apply更新状态，核心原因有两点：

• 保证内存状态与事件流一致：聚合根的内存状态是已发生事件的实时快照。如果生成事件后不更新状态，后续任何依赖当前状态的操作（比如同一个请求里的后续校验、领域服务的逻辑判断）都会拿到错误的旧状态，导致业务规则失效。
• 符合Event Sourcing的状态模型：聚合根的状态本质是所有已提交事件的累加结果。命令处理时生成事件并立即应用，是在模拟“事件已发生”的事实——后续持久化事件后，回放事件也会执行同样的apply逻辑，这样内存状态和事件流的最终结果才能完全匹配，避免状态脱节。

遵循这个模式，哪怕当前业务场景简单，也能保证代码的可维护性和模式一致性，避免后续业务扩展时的重构成本。

内容的提问来源于stack exchange，提问作者ms1403