本文探讨了在事件溯源（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; }}
聚合中处理整合命令的方法：
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与聚合：优雅管理不变性，避免重复检查的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1321284.html
微信扫一扫 
支付宝扫一扫 
