聚合根中不变量管理的挑战
在领域驱动设计（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 命令。聚合根接收这个命令后，可以根据新的上下文（即同时修改价格和可用性）来判断不变量。
优势：
- 意图明确： 命令本身清晰地表达了“同时修改价格和可用性”的业务操作。
- 上下文丰富： 聚合根在处理不变量时，可以同时考虑新价格和新可用性，做出更合理的决策。例如，如果命令将产品设置为“可用”，那么即使当前产品不可用，价格变更也可能被允许。
- 避免重复检查： 领域服务无需关心聚合根的内部不变量，只需发送复合命令。所有不变量检查都在聚合根内部完成。
示例：复合命令的实现
首先定义复合命令：
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;
}
}通过这种调整，即使领域服务不知道产品的当前价格，它也可以安全地尝试更新价格，而不会因为价格未变而引发异常。
注意事项与最佳实践
- 命令的粒度： 仔细考虑命令的粒度。当多个状态变更在业务上紧密相关，且它们的组合影响不变量判断时，考虑使用复合命令。如果变更相对独立，则保持独立命令可能更清晰。
- 不变量的生命周期： 不变量并非一成不变。它们可能在特定的状态转换期间有效，或者在特定业务流程中具有不同的解释。聚合根应根据当前状态和命令上下文动态评估不变量。
- 幂等性： 尽可能使聚合根的操作具有幂等性。如果一个命令旨在将聚合根置于某个特定状态，那么当聚合根已经处于该状态时，重复执行该命令不应产生副作用或错误。
- 领域服务的作用： 领域服务应作为协调者，编排聚合根、存储库和其他领域对象之间的交互。它不应重复聚合根内部的业务逻辑或不变量检查。
- 清晰的错误处理： 当不变量确实被违反时，抛出具有明确业务含义的异常。这有助于调用者理解失败的原因并采取适当的措施。
- 测试： 对聚合根的不变量进行彻底的单元测试，包括各种有效和无效的场景，以及复合命令的复杂交互。
总结
在事件溯源架构中，聚合根的不变量管理是构建健壮领域模型的关键。通过引入复合命令，我们能够为聚合根提供更丰富的上下文信息，从而在处理多重状态变更时更智能地评估不变量，避免了领域服务中重复的逻辑和笨重的错误处理。同时，重新审视不变量的严格性，尤其是在处理“目标已达成”的情况时，可以提升系统的幂等性和鲁棒性，简化客户端代码。这两种策略共同构成了在事件溯源中优雅处理不变量的核心实践，有助于构建清晰、可维护且高度一致的领域模型。
