NestJS多对多关联场景下的模块结构设计方案探讨

需求背景 #

需实现四个REST端点：

• /documents：列出所有文档
• /authors：列出所有作者
• /documents/:id/authors：列出指定文档的作者
• /authors/:id/documents：列出指定作者的文档
  核心诉求是将模块视为潜在独立微服务，兼顾领域边界与模块解耦。

三种方案的优劣分析 #

方案1：仓储跨领域操作 #

• 结构：
  • Documents模块：DocumentsController处理所有/documents*端点，DocumentsRepository包含list()和listAuthorsForDocument(id)方法
  • Authors模块：AuthorsController处理所有/authors*端点，AuthorsRepository包含list()和listDocumentsForAuthor(id)方法
• 问题：违反领域设计核心原则，仓储应仅负责自身聚合根（Document/Author）的读写操作，listAuthorsForDocument这类属于Author领域的查询逻辑，放在DocumentsRepository会导致职责混乱，后续微服务拆分时无法独立复用仓储。

方案2：跨模块导入仓储 #

• 结构：
  • Documents模块：DocumentsController处理/documents*端点，DocumentsRepository包含list()和listByAuthor(id)方法；模块对外暴露AuthorsRepository
  • Authors模块：AuthorsController处理/authors*端点，AuthorsRepository包含list()和listByDocument(id)方法；模块对外暴露DocumentsRepository
• 优缺点：
  • 优点：仓储职责符合领域边界，每个仓储只处理自身聚合根的查询逻辑
  • 缺点：模块间存在硬依赖（Documents模块依赖AuthorsRepository，反之亦然），后续拆分为微服务时，本地依赖需改为远程调用，适配成本高，初期耦合度超标。

方案3：跨路径控制器 #

• 结构：
  • Documents模块：DocumentsController处理/documents和/authors/:id/documents端点，DocumentsRepository包含list()和listByAuthor(id)方法
  • Authors模块：AuthorsController处理/authors和/documents/:id/authors端点，AuthorsRepository包含list()和listByDocument(id)方法
• 优缺点：
  • 优点：模块完全解耦，无跨模块导入依赖，后续微服务拆分时无需调整控制器归属
  • 缺点：违背NestJS控制器路径分组惯例（通常控制器前缀与模块领域一致，如@Controller('/documents')下的接口都属于文档相关），路由结构混乱，增加维护成本。

更优实现方式：领域服务+松耦合调用 #

如果目标是未来拆分为微服务，推荐采用领域服务+松耦合调用的方案，兼顾领域规范与解耦需求：

1. 明确模块与控制器边界：

   • Documents模块：DocumentsController仅处理/documents和/documents/:id/authors端点，严格遵循/documents路径前缀
   • Authors模块：AuthorsController仅处理/authors和/authors/:id/documents端点，严格遵循/authors路径前缀

2. 仓储职责严格对齐领域：

   • DocumentsRepository：仅包含Document聚合根的读写方法：list()、findById(id)
   • AuthorsRepository：仅包含Author聚合根的读写方法：list()、findById(id)、listByDocumentId(docId)（作者关联文档的查询属于Author领域）

3. 松耦合跨模块调用：

   • 单体阶段：通过NestJS的ModuleRef或共享的API服务（而非直接导入仓储）实现跨模块调用，避免仓储依赖
   • 微服务阶段：将跨模块调用替换为消息队列（如RabbitMQ）或HTTP API调用，无需大幅改动业务逻辑

这种方式既保证了领域边界的正确性，又实现了模块低耦合，同时为未来微服务拆分做好了准备，也符合NestJS的路由惯例。

内容的提问来源于stack exchange，提问作者dndr