六边形架构与DDD中Spring应用的DTO层位置选型咨询

核心原则回顾 #

六边形架构的核心是分层隔离：Application层作为对外适配层，负责处理外部请求/响应的格式适配；Domain层是业务核心，只关注业务规则，完全独立于外部细节（包括Web、持久化等）。DTO本质是跨层/跨系统的数据传输载体，其设计需服务于这种边界隔离。

两种方案的利弊分析 #

方案1：严格规范版（DTO放置Application层） #

结构示例：

Application
    DataController (webservice)
    DataDto
    
Domain
    DataService
    DataBean
    Mapper (DataBean → DataDto)
    
Infrastructure
    Mapper (DataEntity → DataBean)
    DataEntity

• 优势：
  • 完全符合六边形架构的隔离原则：Domain层不感知任何外部传输结构，后续即使DTO需要调整（比如前端新增字段、修改字段命名），也不会影响核心业务逻辑。
  • 各层职责清晰：Application层管对外数据格式，Domain层管业务规则，Infrastructure层管持久化细节，边界明确。
• 劣势：
  • 当DTO与DataBean结构完全一致时，存在代码重复，对简单项目来说会增加初期开发和维护的冗余成本。

方案2：简化版（DTO放置Domain层） #

结构示例：

Application
    DataController (webservice)
    
Domain
    DataService
    DataDto
    
Infrastructure
    Mapper (DataEntity → DataDto)
    DataEntity

• 优势：
  • 消除代码重复，减少开发工作量，适合业务逻辑简单、对外数据结构长期稳定的小型项目。
  • 层级更少，代码更简洁，上手成本低。
• 劣势：
  • 打破Domain层的独立性：Domain层直接绑定外部传输结构，后续若外部需要修改DTO格式（比如前端要求返回不同字段），必须改动Domain层对象，违反了DDD中Domain层不受外部影响的核心原则。
  • 扩展性差：当业务复杂度提升，需要区分内部业务对象和外部传输对象时，重构成本会非常高。

最佳实践建议 #

没有绝对的“最优方案”，需结合项目规模和未来演进预期选择：

1. 小型、简单且需求稳定的项目：
   优先选择方案2，以减少重复代码、降低维护成本为核心目标。毕竟DDD和六边形架构的初衷是解决复杂业务的复杂度，简单项目无需过度设计。

2. 中型以上、业务有演进空间的项目：
   必须选择方案1。短期的代码重复换来了长期的架构灵活性，当后续业务变化（比如新增业务规则、外部接口格式调整）时，Domain层可保持稳定，仅需修改Application层的DTO和映射逻辑，避免牵一发而动全身。

另外，可采用折中方案：如果DTO与DataBean结构一致，使用MapStruct等映射工具自动生成映射代码，既遵守架构规范，又降低手动维护重复代码的负担。

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