如果将业务逻辑外包给第三方系统，则设计有界上下文

Question

在我们公司中，有两个主要业务领域，分别是工作订单管理和会计，它们都具有完全成型的通用语言。

上层管理人员决定购买大型第三方系统，该系统应取代我们的旧旧系统。他们需要融入我们事件驱动的企业格局。这些系统将负责涵盖大多数业务逻辑。子域中的用户将使用第三方系统的UI。

与此同时，我们希望开发自定义微服务，该服务将使用反腐败层模式集成这些系统。请参见下图。

ACL将根据我们的通用语言及时从第三方系统提取数据并发布域事件。例如WorkOrderPlaced，InvoicePosted等。

在WorkOrderManagement内，我们希望有聚合的WorkOrder，但实际上，及其业务逻辑的实体是在CAFM第三方系统中管理和存储的。域命名和域结构都无法匹配我们对有限上下文的理解，因此我们（有限上下文微服务的）ACL应该将其转换为我们的世界（尤其是域事件）。

那么，由于不是聚合的主节点，我们的微服务的域层不会解散吗？ 构建我们自己的受限上下文微服务甚至合理吗？如果没有实际的定制开发，使用DDD的战术模式（例如聚合和域服务）会感到很尴尬。例如，强制不变式发生在第三方工具中，而不是在微服务中。