在整洁/洋葱架构中，PDF/Office文档生成应如何定位与落地

核心背景梳理 #

你的报告生成需求存在几个核心矛盾点：跨限界上下文的数据查询需求、附带部分业务逻辑、依赖第三方文档操作框架、需直接访问数据库做性能优化，同时还要兼顾架构的关注点分离与维护成本。

分层方案选择 #

• 最优解：新增独立的Reporting层
  这是最能平衡各需求的方案：
  • 该层可直接引用Domain层（获取业务实体定义）、Infrastructure.DataAccess（满足直接查询的性能要求），同时引入docx/excel操作框架；
  • 对外提供标准化的报告生成接口，由Presentation层直接调用（或根据架构依赖规则，通过Application层转发）；
  • 把跨上下文数据聚合、报告格式编排、专属业务计算逻辑全部封装在此层，避免分散到其他4个层导致维护混乱。
• 备选方案：在Infrastructure层新增Reporting子模块
  若无法新增独立层，可采用此方式：
  • 把报告生成的实现放在Infrastructure层下的专属子模块中，通过抽象接口对外暴露能力；
  • 由Application层调用该接口，避免业务逻辑直接依赖第三方框架细节；
  • 注意做好模块划分，不要让Infrastructure层的职责过于混杂。

避坑提醒 #

• 绝对不要放在Domain层：Domain层需专注核心业务逻辑，禁止依赖第三方框架；
• 不要放在Presentation层：Presentation层负责交互展示，不应承担复杂的数据聚合与业务计算；
• 即使直接访问数据库，也要封装成专用的查询服务，避免在报告代码中写入裸SQL，保证代码可维护性；
• 尽量分离报告业务规则与格式编排逻辑：业务规则贴近Domain层定义，格式编排交给第三方框架处理。

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