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; }
}聚合中处理整合命令的方法：
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 两个独立的事件被记录。事件应该反映“发生了什么”，而不是“我们想做什么”。
- 幂等性： 优雅地处理“无变化”情况有助于实现命令的幂等性。无论命令被执行多少次，只要聚合最终达到期望的状态，就不会产生额外的副作用（即重复的事件）。
- 领域服务与聚合： 如果不变性检查跨越多个聚合，则可能需要领域服务来协调这些聚合。但对于单个聚合内部的不变性，始终应由聚合本身负责。
- 错误处理： 仅当业务规则被真正违反时才抛出异常。对于那些仅仅表示“状态已满足期望”的情况，应返回聚合实例，而不记录事件。
总结
在事件溯源和聚合设计中，有效管理不变性是构建健壮领域模型的关键。通过以下策略，我们可以避免不变性检查的重复，简化客户端代码，并提升系统的可维护性：
- 整合相关命令： 将业务上紧密关联的操作封装到单个命令中，赋予聚合更全面的上下文来执行复杂的、多维度的不变性检查。
- 优化“无变化”处理： 将目标状态已达成的场景视为“无操作”而非错误，避免不必要的异常抛出，并简化客户端的调用逻辑。
遵循这些原则，可以构建出更清晰、更健壮、更易于理解和扩展的聚合，从而更好地支持复杂的业务逻辑。
