DDD:在核心域的有界上下文上分发接口和报告逻辑，或者使用指定的有界上下文(泛型域)？

Question

我们正在开发一个基于领域驱动设计(DDD)的体系结构(从头开始)，大约有三个有界的上下文，每个上下文对应于一个核心域。还有一个有限制的上下文(泛型子域)用于监视我们的应用程序，还有一个有限制的上下文(泛型子域)，用于执行调度任务(来自核心域，但被调度程序视为黑匣子)。

还有两个要求，我们不知道如何对它们建模：

• Reporting (即具有不属于我们域一部分的外部系统的像素精确reports)
• Interfacing (例如，准备一组XML文件，准备在夜间由政府通过web服务(WSDL)获取；或将一个核心域的部分模型公开为一个可供第三方查询的简化SQL数据库)

。

我们可以考虑两种方法，每种方法：

1. 将报表和接口集成到它们所属的有限上下文中，从而可能重复基础结构代码。

- In case of Reporting, we would check-in the report definition files (e.g. Microsoft's RDL) into the Git repositories of the individual Bounded Contexts and deploy them to a centralised reporting server.
- In case of Interfacing, we would develop the aforementioned XML-generation logic and web service as projects in the Git repository of that Bounded Context, and deploy it as part of that Bounded Context too.

​

1. 为报告和接口创建指定的有界上下文，从而统一技术，但分布核心域的各个方面。

- In case of Reporting, we would manage all report definition files belonging to different core domains in a designated Git repository, together with all the code necessary to create and show the reports.
- In case of Interfacing, we would manage all 'ports and adapters' in a single Git repository for all core domains, potentially using a very heterogeneous set of interface technologies like REST or WSDL or OpenAPI or SQL. This Bounded Context would then consume the Published Languages (in our case this is all Web API using Open API standard) of the Bounded Contexts it should interface with, and provide itself the interface for the outside world.

​

我认为讨论可以归结为两个独立的层面:技术和商业。我们应该把所有与业务相关的东西放在一起，还是应该围绕着技术/基础设施(即所有与接口相关的和与报告相关的一切)进行集群？

Answer 1

正如您所指出的，选项1将重复基础结构代码，这听起来像是代码中的一种味道。

选项2将分发核心域的方面，但这很好，因为有界的上下文可以相互通信。

而且，在您的示例中，报告和与外部系统的接口都是它自己的有界上下文，因此它应该是应用程序中的一个单独的层/上下文。