Domain driven design DDD-如何在与第三方系统集成时确保聚合一致性？

这个问题实际上是双重的，重点放在最重要的问题上

聚合定义了系统的一致性和事务边界

假设您的公司通过一个应用程序提供一些服务，而您将通过与第三方的集成来添加新功能。第三方有自己的API，当用户选择使用新功能时，您需要在其系统中创建用户。现在，你不是一个怪物，所以你允许用户关闭这个功能，如果他们以前开始使用它的话。这意味着您还必须能够删除第三方API中的用户

• 如果我们要为这样一个特性设计一个聚合（假设它是一个订阅），我们应该将与第三方API的交互放在哪里

• 如果我们与之集成的第三方允许用户完全绕过我们的应用程序将自己从系统中删除，该怎么办？现在，我们的聚合将不同步

---

通常，聚合不是在系统级别强制一致性，而是在某些数据上强制一致性。这一概念是在中引入的，当时大多数解决方案都依赖于传统的大规模SQL db，其目的是将一致性责任从存储层转移到业务逻辑中。它这样做是因为一致性就是这样：业务逻辑。如果您在出售某些东西时必须减少库存，这是一个一致性规则，应该存在于应用程序代码中，并使用其他业务逻辑，而不是委托给存储过程

考虑到这一点，您所拥有的任何聚合都不会（实际上不能）强制与外部世界保持一致性（不是您拥有和内部持有的数据）。但是，您可以引入两个（或一个组合的）流程管理器：

• 一个流程管理器，执行“当用户请求删除时，将其从外部系统中删除”的策略。这将观察内部请求，并在用户请求删除时呼叫第三方服务删除用户
• 一个流程管理器将强制执行“当用户从第三方服务中被删除时，在我们的系统中也将其标记为已删除”的策略，这与策略所说的差不多

您可能有订阅聚合，也可能没有订阅聚合。如果您需要对您拥有并负责的数据实施某种一致性，那么将决定这一点