用途：为 Swift 与 iOS 应用设计务实的 Clean Architecture 组合，关注职责清晰、依赖显式构造、边界合理，以及满足当前需求的最简设计。适用于组合 iOS 功能或应用、决定 View/ViewModel/Use Case/Repository/Service/Data Source 的交互、定义 Presentation/Application/Domain/Data/Infrastructure 边界、创建组合根或功能工厂、审查依赖注入与依赖方向、隔离网络/持久化/缓存/Keychain/系统 API/外部 SDK、决定 DTO 与领域模型是否分离、组织功能模块或 Swift 包、移除协议与分层样板。不适用于基础 Swift/SwiftUI 语法、UI 样式布局、无依赖含义的文件夹命名、无 Swift/iOS 上下文的后端架构，以及与架构组合无关的性能分析。
核心原则：把 Clean Architecture 主要视为依赖规则而非固定目录结构；默认使用具体类型，仅在解决当前明确问题时引入抽象；在显式组合根中构造具体依赖；当边界有实际价值时，让应用与领域策略独立于基础设施；职责无实质差异时不自动拆分 Application 与 Domain；优先逻辑边界再考虑物理 Swift 模块；保留既有架构，除非改动能解决具体问题；对现有代码库优先做最小修正。
组合层级：不强制每个功能使用相同层数。简单功能可用 View→ViewModel→具体服务；有数据访问策略时可用 View→ViewModel→Repository→API/数据库/缓存/SDK；有应用策略或协调时可用 View→ViewModel→Use Case→Repository 或服务→基础设施。只使用问题所需的层级。
抽象策略：优先具体类型，依赖注入不需要协议。仅当存在多种实现、计划中的第二实现、内层模块需拥有外层实现的能力、确实需要不同运行/预览/离线/缓存/平台/测试实现、需要隔离第三方 SDK 或系统 API、协议定义稳定共享能力、或无法用更简单方式获得测试接缝时，才引入协议。不要仅因“将来可能有实现”“看起来可测试”“每个依赖都应有 mock”“正在使用依赖注入”“正在应用 Clean Architecture”或命名惯例而添加协议。
工作流：先检查现有系统的构造点、依赖方向、模块边界、所有权与生命周期、测试接缝、外部集成与迁移成本；再澄清用户操作、业务规则、所需数据、外部效果、所有权、生命周期与变更原因；然后画出依赖图并逐项追问必要性、能否保持具体、谁创建、存活多久、方向是否正确；接着分离策略与机制，内层逻辑不应构造 URLSession、SwiftData/Core Data 容器、Keychain、分析 SDK、缓存、文件系统或外部服务；再决定是否需要 Use Case（仅在强制规则、校验、协调多依赖、定义顺序/回滚/补偿/事务、代表重要命名动作、多入口复用或提供应用边界时创建，按用户或系统动作命名，如 LoadProducts、AddProductToCart、SubmitOrder、RefreshSession）；决定是否需要 Repository（仅在隐藏远程与本地协调、缓存失效、同步、离线回退、持久化、新鲜度、冲突解决或组合多种数据机制时创建，避免每端点一个仓库、全局仓库、通用 CRUD 仓库或仅重命名客户端调用的仓库）；仅在有用时添加 Data Source；按语义差异决定模型边界，避免无差别复制模型；在应用组合根或功能级组合点构造具体依赖，不在 View、ViewModel、Use Case 或领域实体中构造基础设施；明确依赖生命周期（应用级、会话级、功能级、屏幕级、操作级），不要全部单例；优先逻辑边界，仅在编译期强制、所有权、复用、可见性、构建结构或团队边界需要时引入 SwiftPM 目标或模块；最后移除意外复杂度，检查协议能否具体化、Use Case 能否删除、Repository 是否仅转发、Data Source 是否只增加间接层、模型是否无谓重复、工厂是否只包装一个初始化器、每个抽象是否有当前需求依据、改动是否小于重写、依赖图是否更易理解。
决策规则：必需依赖优先初始化器注入；默认具体类型；小型可注入行为优先值与闭包；协议仅用于有意义的能力、替换、集成或模块边界；协议优先由消费模块拥有；Use Case 用于应用策略或协调而非自动转发；Repository 用于有意义的数据访问策略而非每次 API 调用；优先功能级组合而非构建所有屏幕的全局容器；优先显式构造而非隐藏依赖查找；优先领域导向 API 而非网络导向 API；优先测试具体行为而非为每个类型创建 mock；优先增量修正而非推测性重设计。
常见陷阱：不要把 Presentation/Application/Domain/Data 文件夹当作 Clean Architecture 的证明；不要按惯例创建 Protocol 与 Default 配对；不要声称依赖注入需要协议；不要每个 Repository 方法一个 Use Case；不要每个端点一个 Repository；领域能力不同时不要引入通用 CRUD 仓库；不要把 Use Case 放进 Repository 实现；不要在 ViewModel 或 Use Case 中构造基础设施；不要用服务定位器替代显式组合；审查遗留服务定位器代码时优先增量迁移到显式初始化器注入；不要无语义差异地复制模型；不要把每个逻辑层拆成 Swift 包；抽象原因消失后不要保留它。
输出期望：按请求深度匹配响应。聚焦问题给出决策、理由与最小示例；完整设计或审查包含功能与用户场景、依赖方向、紧凑依赖图、主要组件职责、应保持具体的依赖、引入的协议及各自具体原因、提供有意义策略或协调的 Use Case、应省略的层或抽象、组合根位置、重要依赖生命周期、最小 Swift 示例、测试策略、迁移成本与权衡。审查现有代码时识别推测性协议、不必要 Use Case、直通 Repository 或 Data Source、隐藏依赖构造、错误依赖方向、基础设施泄漏到应用逻辑、不必要模型重复、所有权或生命周期不清、超出必要的改动。
验证：最终设计前确认具体实现创建于组合中、每个抽象有当前明确理由、已考虑移除每个协议、每个 Use Case 提供策略/协调/复用/有意边界、Repository API 使用应用或领域语言、外部 DTO 与 SDK 类型不跨不当边界泄漏、依赖生命周期在重要处显式、无需 mock 每个类型即可测试、改动尊重现有代码库、结果不比问题所需更复杂。
参考文件：references/use-cases-and-repositories.md 用于决定是否需要 Use Case、Repository、Repository 协议、服务或 Data Source，或审查薄直通层；references/composition-root.md 用于构建应用容器、功能工厂、导航组合、依赖生命周期、SwiftUI 预览、测试组合或会话级图；references/boundaries-and-models.md 用于分离 DTO、持久化模型、领域模型、视图数据、外部 SDK、逻辑层或 Swift 模块边界。