我们正在开发一种基于领域驱动设计(DDD(的架构(从头开始(，大约有三个有界上下文，每个上下文对应一个核心领域。还有一个用于监控我们的应用程序的有界上下文(通用子域(，以及一个用于执行计划作业(来自核心域，但被调度程序视为黑匣子(的有界语境(通用子域(。
还有两个我们不确定如何建模的要求：
- 报告(即像素精确报告(
- 与不属于我们领域的外部系统接口(例如，准备一堆XML文件，准备在夜间由政府通过web服务(WSDL(获取；或者将一个核心域的模型的一部分公开为简化的SQL数据库，以便第三方查询(
我们可以分别想到两种方法：
-
将报告和接口集成到它们所属的绑定上下文中，从而可能复制基础结构代码。
- 在报告的情况下，我们会将报告定义文件(例如Microsoft的RDL(签入到单个Bounded Contexts的Git存储库中，并将它们部署到集中的报告服务器上
- 在Interface的情况下，我们将在该Bounded Context的Git存储库中开发上述XML生成逻辑和web服务作为项目，并将其作为该Bounted Context的一部分进行部署
-
为每个报告和接口创建指定的有界上下文，从而统一技术，但分布核心域的各个方面。
- 在报告的情况下，我们将在指定的Git存储库中管理属于不同核心域的所有报告定义文件，以及创建和显示报告所需的所有代码
- 在接口的情况下，我们将在一个Git存储库中为所有核心域管理所有"端口和适配器"，可能会使用一组非常异构的接口技术，如REST或WSDL、OpenAPI或SQL。然后，这个边界上下文将使用它应该与之接口的边界上下文的已发布语言(在我们的情况下，这是使用Open API标准的所有Web API(，并为自己提供与外部世界的接口
我认为讨论可以归结为两个独立的维度：技术和业务。我们应该把所有与业务相关的东西放在一起，还是应该围绕技术/基础设施(即所有与接口相关的东西和所有与报告相关的东西(进行集群？
正如您所指出的，选项1会复制基础设施代码，这听起来像是代码中的气味。
选项2将分配核心域的方面，但这很好，因为有界上下文可以相互通信。
此外，在您的情况下，报告和与外部系统的接口都是自己的有界上下文，因此它应该是应用程序中的一个单独的层/上下文。