.NET Clean Architecture中全球化本地化资源文件夹及文件存放位置

核心判断标准只有一个：资源文件跟着使用职责走，严格匹配各层的依赖边界，不要全量堆在某一层。

• Domain层：禁止存放任何本地化资源文件
  Domain层是整个架构的核心，只承载领域实体、领域规则、核心业务抽象，必须保持零外部依赖、无任何交互/展示类逻辑。本地化文本属于面向交互或者业务流程编排的内容，放在这一层会直接破坏领域层的纯净性，违反架构依赖规则。
• Application层：存放全项目共享的业务类本地化资源
  在这一层新建Resources文件夹，存放和具体UI框架、具体基础设施实现无关的多语言内容，包括：业务校验规则的提示文本、业务操作返回的状态消息、领域枚举对应的对外展示文本、应用服务层通用的错误提示等。这部分资源不绑定任何具体的入口端或者实现细节，所有上层都可以直接复用，不会产生反向依赖。
• Infrastructure层：仅存放和基础设施实现强绑定的本地化资源
  只有这一层的实现逻辑会用到的多语言内容，直接在本层新建Resources文件夹存放即可，不需要下沉或者上移。常见的这类资源包括：第三方通知服务（短信、邮件）的多语言模板、文件导入导出模块的固定提示文本、基础设施组件自身的异常提示文案等，避免上层引用到基础设施的实现细节。
• WebApp层（展示/入口层）：存放仅和前端页面交互相关的本地化资源
  只在Web端用到的展示类多语言内容，直接放在这一层的Resources文件夹下即可，可以按页面、视图组件、控制器分目录管理。常见的这类资源包括：页面按钮/导航/标题的固定文本、前端交互的即时提示文案、视图绑定的静态展示内容等，这类资源不需要下沉到下层，其他架构层根本不会用到。

常见踩坑提醒：不要图省事儿把所有资源文件全堆在WebApp层。如果后续新增其他入口端（比如移动端API、后台任务服务、对外开放接口），要复用业务相关的多语言文本时，就会出现下层反向引用WebApp层的问题，直接违反Clean Architecture的依赖方向规则。

注册本地化服务时不需要手动把所有资源复制到WebApp层，.NET自带的本地化中间件会自动按类型的命名空间，查找对应程序集内嵌入的资源文件，正常在入口层的Program.cs中注册服务即可：

builder.Services.AddLocalization();
// 按需配置请求文化提供器，支持按路由、请求头、Cookie判断用户使用的语言即可

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