Service DDD：阻止外部服务调用和事件

我一直在探讨将外部服务集成到我的域中的最佳方法

有许多第三方服务可以使用，因此我们有一个适配器提供公共接口。我们在任何时候都只有X个可用的服务实例（创建和销毁这些实例的成本很高），因此可以从池中检索它们

外部服务用作长时间运行流程的一部分。该流程将由流程经理实施。一个实体被调度，然后向对象池请求资源，当资源空闲时，它执行一个操作，然后记录结果，并将资源返回到对象池。这个过程的两个部分（请求一个空闲资源和执行一个操作）可能需要一些时间，并且会阻塞调用。理想情况下，这些应该异步完成

这意味着外部服务需要在资源空闲时以及在计算了操作的结果时引发事件。我看到的每个例子都提供了从集合中引发事件的指导。当外部系统（在本例中是一个通用子域？）需要报告事件时，几乎不需要报告事件……因此我的问题是：

• 我的理解是，任何外部服务基本上都是一个独立的有界上下文。在这种情况下，适配器和池通过将服务隐藏在公共接口后面，基本上起到ACL的作用。这个假设正确吗

• 我需要从封装外部服务的适配器/池引发事件。ACL通常作为域服务实现，但常见的建议是不要从服务引发事件。我的理由是域服务是一个接口，实现（基础设施）将继续进行，并根据需要引发事件。这些基本上是集成事件，而不是典型的域事件。我不拥有BC，只有适配器，所以关于域事件/聚合的典型指南就不存在了？直接把事情提出来

• 在Process Manager从池中请求资源的实例中。Process Manager是否直接调用适配器？或者这应该是一个命令？即使命令本质上只是请求一个资源（即对实体没有状态更改）

• 在这种情况下，有没有最佳的引发事件的方法？同样，如果我决定用基本事务脚本实现一个支持子域。假设您只需要根据需要从ACL将事件直接引发到总线。没有域模型，所以一切都是集成事件

• 纯粹出于理论目的，因为我最好尝试理解这些概念。存储库实质上是包装第三方持久性服务。持久化技术是一个有界上下文，而存储库是一个ACL/适配器的推理在技术上正确吗

---

我一直在努力寻找更多关于上述内容的具体指导，因此，任何建议都将不胜感激。

在做了一些进一步的研究之后，我将尝试回答我自己的问题

我的理解是，任何外部服务基本上都是独立的 有界上下文。在这种情况下，适配器和池基本上是 通过将服务隐藏在公共目录后面，作为ACL运行 接口。这个假设正确吗

对。这都是关于语言的。显然，任何外部服务的实现都使用完全不同的语言，因此必须是单独的有界上下文。我们可以选择与该BC保持一致的关系，但这使我们与第三方服务紧密结合。因此，我们需要一些东西来与我们语言中的另一个有界语境“对话”。称它为适配器、网关，不管怎样，它充当ACL

我需要从我的适配器/池中引发事件来包装外部 服务ACL通常作为域服务实现，但是 建议不要从服务中引发事件。我的理由是 域服务是一个接口，它的实现 （基础设施）根据需要开展活动。这些是 本质上是集成事件，而不是典型的域事件。我 不拥有BC，只拥有适配器，所以域上的典型指南 事件/聚合是否已退出窗口？把这件事提出来 直接的

我觉得关于领域事件的文献有时会有点误导。域事件的核心概念是：域中发生的事情。但随着时间的推移，这一概念开始与许多不同但相关的事情融合在一起：CQR中的读取模型预测、最终一致性、事件源和跨有限上下文的通信。因此，我们必须定义域事件在我们的系统中对我们意味着什么

域事件是域中发生变化的记录，因此逻辑上只能由聚合引发。然后选择是否侦听和处理这些事件。您还可以决定是在事务内部处理，还是在事务外部处理。我们选择内部处理

在这之后，我相信我们现在正在进入信息传递阶段。没有什么可以说您不能将域事件发布为消息，但是它已经变得有点不同了，或者更确切地说：现在有了额外的用途。一种类型的消息是事件，它不必是域事件。因此，如果有意义的话，我可以从适配器中提升。在本例中，它表示我的BC之外的事件。尽管对该事件的处理可能会导致BC中的域事件。正是这些消息使我们能够实现最终的一致性，跨BCs进行通信等。您可以将它们称为集成事件、公共事件、外部事件和异步事件。如果愿意，请在发布之前翻译域事件，或者直接发布它们。在这一点上，无论您使用的是不同的c语言，它们都是一条消息