Event Sourcing与聚合：优雅管理不变性，避免重复检查-php教程-PHP中文网

Event Sourcing与聚合：优雅管理不变性，避免重复检查

心靈之曲

发布： 2025-09-24 10:01:09

原创

911人浏览过

event sourcing与聚合：优雅管理不变性，避免重复检查

本文探讨了在事件溯源（Event Sourcing）架构中，聚合（Aggregates）如何高效且不重复地处理业务不变性（invariants）。通过整合相关命令和重新思考“无变化”场景的错误处理，可以优化聚合设计，避免代码冗余，并提升系统的健壮性和可维护性，尤其在处理外部数据更新时。

1. 聚合中不变性检查的挑战

在基于事件溯源的领域驱动设计中，聚合是业务不变性的边界。聚合负责确保其内部状态始终保持有效，这通常通过在其方法中执行不变性检查来实现。然而，当操作涉及多个相关属性，并且这些操作可能由外部源触发时，如何优雅地处理这些不变性检查，避免代码重复和复杂的错误处理逻辑，成为一个常见挑战。

考虑以下一个 ProductAggregateRoot 的示例，其中 changePrice 方法包含了两个不变性检查：

public function changePrice(ChangeProductPrice $command): self
{
    // 不变性检查1：产品不可用时不能更改价格
    if ($this->availability->equals(Availability::UNAVAILABLE())) {
        throw CannotChangePriceException::unavailableProduct();
    }

    // 不变性检查2：如果价格未发生变化，则抛出异常
    if ($this->price->equals($command->newPrice)) {
        throw CannotChangePriceException::priceHasntChanged();
    }

    $this->recordThat(
        new ProductPriceChanged($this->price, $command->newPrice)
    );

    return $this;
}

登录后复制

当需要从外部数据源同步产品的价格和可用性时，如果采用分别调用 changePrice 和 changeAvailability 方法的方式，可能导致以下问题：

重复的错误处理逻辑： 外部服务需要为每个操作包裹 try-catch 块，例如：

try {
    $aggregate->changePrice(new ChangeProductPrice(
        $productId,
        $state->getPrice()
    ));
} catch (CannotChangePriceException $ex) {
    // 处理价格变更失败
}

try {
    $aggregate->changeAvailability(new ChangeProductAvailability(
        $productId,
        $state->getAvailability()
    ));
} catch (CannotChangeAvailabilityException $ex) {
    // 处理可用性变更失败
}

登录后复制

这种方式不仅冗长，而且难以处理多个操作之间的上下文关联。

不变性检查的重复： 如果为了在调用聚合方法前进行预检查，而在外部服务中也实现 canChangePrice() 这样的方法，将导致不变性逻辑在聚合内部和外部的双重存在，增加了维护成本和出错风险。

2. 整合命令以实现上下文感知的检查

解决上述问题的关键在于重新思考命令的粒度。当多个属性的变更在业务上是紧密关联的，并且它们的有效性检查需要相互协作时，应该将这些操作封装到一个更高级别的命令中。

例如，与其分别处理价格和可用性，不如创建一个 UpdateProductDetails 或 ChangeProductPriceAndAvailability 这样的命令。这个命令将包含所有相关信息，并传递给聚合的一个新方法。

新的命令示例：

final class UpdateProductDetails
{
    public function __construct(
        private ProductId $productId,
        private Money $newPrice,
        private Availability $newAvailability
    ) {}

    public function getProductId(): ProductId { return $this->productId; }
    public function getNewPrice(): Money { return $this->newPrice; }
    public function getNewAvailability(): Availability { return $this->newAvailability; }
}

登录后复制

聚合中处理整合命令的方法：

降重鸟

要想效果好，就用降重鸟。AI改写智能降低AIGC率和重复率。

113

查看详情

class ProductAggregateRoot // ...
{
    public function updateDetails(UpdateProductDetails $command): self
    {
        // 假设我们允许在产品不可用时更新其可用性，但价格更新仍受可用性限制。
        // 通过整合命令，聚合可以获得更全面的上下文。

        // 检查价格变更的不变性：
        // 如果产品当前不可用，且新的可用性也不是“可用”，则不允许价格变更。
        // 或者，如果新的可用性是“可用”，则可以忽略当前可用性状态对价格变更的限制。
        if ($this->availability->equals(Availability::UNAVAILABLE()) && 
            !$command->getNewAvailability()->equals(Availability::AVAILABLE())) {
            // 如果产品当前不可用，且更新后仍不可用，则不能更改价格
            if (!$this->price->equals($command->getNewPrice())) {
                throw CannotChangePriceException::unavailableProduct();
            }
        }

        // 处理价格变更
        if (!$this->price->equals($command->getNewPrice())) {
            $this->recordThat(
                new ProductPriceChanged($this->price, $command->getNewPrice())
            );
        }

        // 处理可用性变更
        if (!$this->availability->equals($command->getNewAvailability())) {
            $this->recordThat(
                new ProductAvailabilityChanged($this->availability, $command->getNewAvailability())
            );
        }

        return $this;
    }
}

登录后复制

通过这种方式，聚合在 updateDetails 方法中可以一次性访问所有相关的输入，从而执行更具上下文感知的、更强大的不变性检查。外部服务只需要发送一个命令，聚合内部负责所有复杂的业务逻辑和不变性验证。

3. 重新思考“无变化”的错误处理

原始 changePrice 方法中的 priceHasntChanged 异常值得商榷。如果一个命令表达的是“我希望价格成为 X”，而当前价格已经是 X，那么这通常不应该被视为一个错误，而是一个“无操作”（no-op）行为。

将“无变化”视为错误会迫使调用者在发送命令前先查询聚合的当前状态，这违背了命令的意图——命令应该表达意图，而不是要求先知。

优化后的聚合方法示例：

public function changePrice(ChangeProductPrice $command): self
{
    // 不变性检查：产品不可用时不能更改价格
    if ($this->availability->equals(Availability::UNAVAILABLE())) {
        throw CannotChangePriceException::unavailableProduct();
    }

    // 如果价格未发生变化，则不记录事件，直接返回聚合实例
    if ($this->price->equals($command->newPrice)) {
        return $this; // 视为无操作，不抛出异常
    }

    $this->recordThat(
        new ProductPriceChanged($this->price, $command->newPrice)
    );

    return $this;
}

登录后复制

在 updateDetails 方法中，同样可以应用此原则：

public function updateDetails(UpdateProductDetails $command): self
{
    // ... (不变性检查逻辑，例如对价格的可用性限制) ...

    $events = [];

    // 处理价格变更
    if (!$this->price->equals($command->getNewPrice())) {
        $events[] = new ProductPriceChanged($this->price, $command->getNewPrice());
    }

    // 处理可用性变更
    if (!$this->availability->equals($command->getNewAvailability())) {
        $events[] = new ProductAvailabilityChanged($this->availability, $command->getNewAvailability());
    }

    // 如果有任何事件需要记录，则记录它们
    if (!empty($events)) {
        foreach ($events as $event) {
            $this->recordThat($event);
        }
    }

    return $this;
}

登录后复制

通过这种方式，如果所有期望的变更都与当前状态一致，聚合将不会记录任何事件，并且不会抛出异常。这使得客户端代码更简洁，不需要预先检查状态，也更符合命令式编程的风格。

4. 最佳实践与注意事项

命令粒度与业务意图： 命令的粒度应与业务意图相匹配。当一系列操作在业务上构成一个不可分割的单元时，应将其封装为一个命令。这有助于聚合在执行不变性检查时拥有足够的上下文信息。
聚合职责的单一性： 聚合应专注于其内部不变性的维护。所有影响聚合状态的决策和验证都应在其内部完成。外部服务或应用层应只负责发送命令，而不应重复聚合的业务逻辑。
事件的粒度： 尽管命令可以被整合，但生成的事件应保持其原子性。例如，一个 UpdateProductDetails 命令可能导致 ProductPriceChanged 和 ProductAvailabilityChanged 两个独立的事件被记录。事件应该反映“发生了什么”，而不是“我们想做什么”。
幂等性： 优雅地处理“无变化”情况有助于实现命令的幂等性。无论命令被执行多少次，只要聚合最终达到期望的状态，就不会产生额外的副作用（即重复的事件）。
领域服务与聚合： 如果不变性检查跨越多个聚合，则可能需要领域服务来协调这些聚合。但对于单个聚合内部的不变性，始终应由聚合本身负责。
错误处理： 仅当业务规则被真正违反时才抛出异常。对于那些仅仅表示“状态已满足期望”的情况，应返回聚合实例，而不记录事件。

总结

在事件溯源和聚合设计中，有效管理不变性是构建健壮领域模型的关键。通过以下策略，我们可以避免不变性检查的重复，简化客户端代码，并提升系统的可维护性：

整合相关命令： 将业务上紧密关联的操作封装到单个命令中，赋予聚合更全面的上下文来执行复杂的、多维度的不变性检查。
优化“无变化”处理： 将目标状态已达成的场景视为“无操作”而非错误，避免不必要的异常抛出，并简化客户端的调用逻辑。

遵循这些原则，可以构建出更清晰、更健壮、更易于理解和扩展的聚合，从而更好地支持复杂的业务逻辑。

以上就是Event Sourcing与聚合：优雅管理不变性，避免重复检查的详细内容，更多请关注php中文网其它相关文章！