Clean Architecture后端API的i18n逻辑分层架构疑问

一、i18n的核心分层原则 #

Clean Architecture的核心是领域层独立于外部依赖，i18n的职责要分场景区分：

• 响应消息的本地化属于「展示/交付层」范畴，应与领域层隔离
• 多语言数据的业务过滤（比如按语言查询翻译表数据）属于「领域层」业务逻辑的一部分

1. 响应消息本地化（交付层职责） #

这类i18n完全可以放在controller或专门的响应处理中间件中实现：

• 领域用例执行后，返回包含业务状态码/错误码的通用结果，而非硬编码的文本消息
• controller或中间件根据请求头的Accept-Language参数，调用i18n服务将状态码转换为对应语言的消息
• 这种方式让领域层只聚焦业务逻辑，不关心消息的展示格式

2. 多语言数据过滤（领域层职责） #

你提到的数据库翻译表按语言过滤，属于业务规则允许的查询维度，应在领域层处理：

• 把语言标识（如zh-CN）作为用例的输入参数传递给领域层
• 领域用例在调用仓储接口时，带上语言过滤条件
• 基础设施层的仓储实现类负责与翻译表交互，执行具体的多语言查询逻辑
• 这种设计既保持了领域层的独立性（语言参数是业务输入，而非外部依赖），又满足了多语言数据查询需求

二、具体问题解答 #

controller调用i18n服务是否可行？ #

完全可行，且是推荐方案。controller属于Clean Architecture的交付层，负责处理HTTP请求与响应，本地化响应消息本来就是它的职责之一。这样领域层无需依赖i18n框架，保持纯净。

i18n是否属于领域层？ #

分场景判断：

• 响应消息本地化：不属于，归属于交付层
• 多语言数据的业务规则（如必须按用户偏好语言返回数据、多语言字段的校验逻辑）：属于领域层，但这里的「i18n」是作为业务参数存在，而非直接调用外部i18n服务

三、项目结构规划建议 #

可以单独拆分i18n模块，但按分层归属划分职责：

• 交付层：放置i18n消息加载、消息转换的工具类/服务，供controller或响应中间件调用
• 领域层：定义语言标识的值对象（如Locale），在仓储接口中声明需要语言参数的方法
• 基础设施层：实现仓储接口时，处理翻译表的多语言查询逻辑

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