事件溯源与聚合根：不变量处理的艺术与实践-php教程-PHP中文网

事件溯源与聚合根：不变量处理的艺术与实践

本文探讨了在事件溯源架构中，聚合根（Aggregate Root）如何高效且优雅地处理业务不变量（Invariants），尤其是在与外部数据源交互或执行复合操作时。我们将分析重复不变量检查带来的问题，并提出两种核心策略：引入复合命令以提供更丰富的上下文，以及重新审视不变量的严格性以实现更灵活和幂等的行为，从而构建更健壮、可维护的领域模型。

聚合根中不变量管理的挑战

在领域驱动设计（ddd）和事件溯源（event sourcing）的实践中，聚合根（aggregate root）是业务规则和不变量的守护者。它封装了其内部实体的状态和行为，并确保任何操作都不会破坏其一致性。然而，当聚合根需要响应来自外部系统的数据更新，或者执行涉及多个状态变更的复杂操作时，不变量的管理可能会变得复杂。

考虑一个 ProductAggregateRoot 聚合根，其中包含 changePrice 方法，用于修改产品的价格。该方法内部定义了关键的业务不变量：

产品不可用时不能修改价格。
如果新价格与当前价格相同，则不应进行修改。

其初始实现可能如下所示：

class ProductAggregateRoot // extends AbstractAggregateRoot
{
    private ProductId $id;
    private Price $price;
    private Availability $availability;

    // ... 构造函数和 apply 方法省略 ...

    public function changePrice(ChangeProductPrice $command): self
    {
        if ($this->availability->equals(Availability::UNAVAILABLE())) {
            throw CannotChangePriceException::unavailableProduct();
        }

        if ($this->price->equals($command->newPrice)) {
            throw CannotChangePriceException::priceHasntChanged();
        }

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

        return $this;
    }
}

登录后复制

现在，假设我们有一个领域服务，负责从外部数据源获取产品价格和可用性信息，并尝试更新聚合根。如果简单地为每个属性更新都调用聚合根的方法，并使用 try-catch 块来捕获不变量违规，代码会显得冗余且不够优雅：

class ProductExternalSyncService
{
    private ProductRepository $productRepository;

    public function __construct(ProductRepository $productRepository)
    {
        $this->productRepository = $productRepository;
    }

    public function syncProductData(ProductId $productId, ExternalProductData $externalData): void
    {
        $aggregate = $this->productRepository->get($productId);

        try {
            $aggregate->changePrice(new ChangeProductPrice(
                $productId,
                $externalData->getPrice()
            ));
        } catch (CannotChangePriceException $ex) {
            // 处理异常，或者选择忽略
        }

        try {
            // 假设有一个 changeAvailability 方法
            $aggregate->changeAvailability(new ChangeProductAvailability(
                $productId,
                $externalData->getAvailability()
            ));
        } catch (CannotChangeAvailabilityException $ex) {
            // 处理异常
        }

        $this->productRepository->save($aggregate);
    }
}

登录后复制

这种模式不仅导致代码重复（领域服务需要“知道”聚合根的某些不变量），而且 try-catch 块的使用也显得笨重，难以清晰表达业务意图。更进一步，如果希望在领域服务中预先检查 CanChangePrice()，又会面临不变量逻辑重复的问题。

策略一：引入复合命令

当多个相关的状态变更需要作为一个整体进行时，引入一个复合命令（Composite Command）是更优的选择。这个复合命令能够更准确地表达业务意图，并为聚合根提供更丰富的上下文信息，从而更智能地处理不变量。

例如，当外部系统同时更新产品的价格和可用性时，我们可以定义一个 ChangeProductPriceAndAvailability 命令。聚合根接收这个命令后，可以根据新的上下文（即同时修改价格和可用性）来判断不变量。

优势：

意图明确： 命令本身清晰地表达了“同时修改价格和可用性”的业务操作。
上下文丰富： 聚合根在处理不变量时，可以同时考虑新价格和新可用性，做出更合理的决策。例如，如果命令将产品设置为“可用”，那么即使当前产品不可用，价格变更也可能被允许。
避免重复检查： 领域服务无需关心聚合根的内部不变量，只需发送复合命令。所有不变量检查都在聚合根内部完成。

示例：复合命令的实现

首先定义复合命令：

沁言学术

你的论文写作AI助理，永久免费文献管理工具，认准沁言学术

查看详情

final class ChangeProductPriceAndAvailability
{
    public ProductId $productId;
    public Price $newPrice;
    public Availability $newAvailability;

    public function __construct(ProductId $productId, Price $newPrice, Availability $newAvailability)
    {
        $this->productId = $productId;
        $this->newPrice = $newPrice;
        $this->newAvailability = $newAvailability;
    }
}

登录后复制

接着，在 ProductAggregateRoot 中添加处理此复合命令的方法：

class ProductAggregateRoot // extends AbstractAggregateRoot
{
    // ... 现有属性和方法 ...

    public function changePriceAndAvailability(ChangeProductPriceAndAvailability $command): self
    {
        $oldPrice = $this->price;
        $oldAvailability = $this->availability;
        $newPrice = $command->newPrice;
        $newAvailability = $command->newAvailability;

        // 核心不变量检查：如果最终状态是不可用，则不允许修改价格。
        // 这意味着，如果命令将产品设置为不可用，并且同时尝试修改价格，
        // 那么这个价格修改是不被允许的。
        if ($newAvailability->equals(Availability::UNAVAILABLE()) && !$oldPrice->equals($newPrice)) {
            throw CannotChangePriceException::unavailableProduct(); // 产品不可用时不能修改价格
        }

        // 记录可用性变更事件
        if (!$oldAvailability->equals($newAvailability)) {
            $this->recordThat(new ProductAvailabilityChanged($oldAvailability, $newAvailability));
        }

        // 记录价格变更事件
        // 只有当价格实际发生变化时才记录
        if (!$oldPrice->equals($newPrice)) {
            $this->recordThat(new ProductPriceChanged($oldPrice, $newPrice));
        }

        return $this;
    }
}

登录后复制

现在，领域服务可以更简洁地调用聚合根，无需处理多个 try-catch 块：

class ProductExternalSyncService
{
    private ProductRepository $productRepository;

    public function __construct(ProductRepository $productRepository)
    {
        $this->productRepository = $productRepository;
    }

    public function syncProductData(ProductId $productId, ExternalProductData $externalData): void
    {
        $aggregate = $this->productRepository->get($productId);

        // 使用复合命令，一次性处理价格和可用性更新
        $aggregate->changePriceAndAvailability(new ChangeProductPriceAndAvailability(
            $productId,
            $externalData->getPrice(),
            $externalData->getAvailability()
        ));

        $this->productRepository->save($aggregate);
    }
}

登录后复制

策略二：重新审视不变量的严格性

某些不变量的严格性可能需要重新评估，以实现更灵活和幂等的行为。例如，“如果新价格与当前价格相同，则抛出异常”这个不变量。从业务角度看，如果目标状态（期望的价格）已经达成，这通常不应该被视为一个错误。相反，聚合根可以简单地接受这个“变更”并返回自身，而不记录任何事件。这符合幂等性原则，即重复执行同一操作产生相同的结果。

优势：

简化客户端逻辑： 客户端（如领域服务）无需预先检查当前价格，可以直接发送命令。
提高幂等性： 即使重复发送相同价格的命令，也不会导致错误或不必要的事件。
更符合直觉： 如果请求的目标状态已经满足，通常不需要抛出异常。

示例：修改 changePrice 方法

class ProductAggregateRoot // extends AbstractAggregateRoot
{
    // ... 现有属性和方法 ...

    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;
    }
}

登录后复制

通过这种调整，即使领域服务不知道产品的当前价格，它也可以安全地尝试更新价格，而不会因为价格未变而引发异常。

注意事项与最佳实践

命令的粒度： 仔细考虑命令的粒度。当多个状态变更在业务上紧密相关，且它们的组合影响不变量判断时，考虑使用复合命令。如果变更相对独立，则保持独立命令可能更清晰。
不变量的生命周期： 不变量并非一成不变。它们可能在特定的状态转换期间有效，或者在特定业务流程中具有不同的解释。聚合根应根据当前状态和命令上下文动态评估不变量。
幂等性： 尽可能使聚合根的操作具有幂等性。如果一个命令旨在将聚合根置于某个特定状态，那么当聚合根已经处于该状态时，重复执行该命令不应产生副作用或错误。
领域服务的作用： 领域服务应作为协调者，编排聚合根、存储库和其他领域对象之间的交互。它不应重复聚合根内部的业务逻辑或不变量检查。
清晰的错误处理： 当不变量确实被违反时，抛出具有明确业务含义的异常。这有助于调用者理解失败的原因并采取适当的措施。
测试： 对聚合根的不变量进行彻底的单元测试，包括各种有效和无效的场景，以及复合命令的复杂交互。

总结

在事件溯源架构中，聚合根的不变量管理是构建健壮领域模型的关键。通过引入复合命令，我们能够为聚合根提供更丰富的上下文信息，从而在处理多重状态变更时更智能地评估不变量，避免了领域服务中重复的逻辑和笨重的错误处理。同时，重新审视不变量的严格性，尤其是在处理“目标已达成”的情况时，可以提升系统的幂等性和鲁棒性，简化客户端代码。这两种策略共同构成了在事件溯源中优雅处理不变量的核心实践，有助于构建清晰、可维护且高度一致的领域模型。

以上就是事件溯源与聚合根：不变量处理的艺术与实践的详细内容，更多请关注php中文网其它相关文章！