DDD洋葱架构下供基础设施与表示层共用的配置模型能否放在应用层

你完全可以在应用层定义公共配置模型，这是符合洋葱架构依赖规则的合理实现方式。

核心逻辑依据 #

洋葱架构的核心规则是外层依赖内层，内层不感知外层实现细节，你在应用层定义的是纯数据结构的配置契约，不包含任何持久化实现逻辑，完全符合你对「应用层轻薄、无持久化细节」的要求，不属于违规设计。
这种方案本质是把配置模型转化为各层共用的抽象契约：

• 表示层可以直接读取、修改配置模型字段，作为参数传递给应用层服务
• 基础设施层的持久化实现依赖应用层的配置契约，根据配置选择存储方式、计算存储路径，不需要重复定义同构的配置结构

存储路径跨层传递的实现方案 #

你不需要把存储路径这类非领域属性塞进领域实体，两种合规的实现方式都可以满足需求：

• 方案1：在应用层定义专门的展示DTO，封装领域实体和对应的存储路径属性。基础设施层执行完持久化/查询操作后，将路径返回给应用层服务，应用层把领域实体和路径组装成DTO返回给表示层即可，全程领域层完全感知不到路径的存在，符合领域层纯业务逻辑的要求
• 方案2：如果路径和实体查询强绑定，可以在应用层定义的仓储抽象接口上声明额外的返回参数，基础设施层的仓储实现类在查询实体的同时返回对应存储路径，应用层直接获取后传递给表示层即可

优化建议 #

• 配置模型注意拆分通用配置和持久化专属配置，不要混放，方便后续扩展其他类型的配置
• 可以在应用层单独创建Contracts/Dtos目录存放这类公共契约，和应用服务的业务协调代码隔离开，保持应用服务本身的轻薄属性

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