一篇来自团队 lead 的实战梳理，对比 8 种 React Native 项目目录结构各自解决什么问题，以及 "Domain-Driven" 和 "Micro-Frontend" 两个标签常被误用的地方。选错结构，代码库要么能吸收更多功能和工程师，要么在自身重量下崩塌、最后专门招人来重写。
八种结构速览：
• Flat Structure：所有文件平铺在 src/，适合原型、hackathon、单屏 demo；超过 10-15 个文件后难以定位。
• Feature-Based：按产品功能划分，auth、feed 各自拥有 components、screens、services，是生产环境最常见结构；但功能文件夹本身不强制隔离，跨功能 import 一多就退回扁平结构，需用 lint 规则约束。
• Layered：按技术角色分组（components、screens、services），适合小团队；缺点是 components 和 screens 会变成大杂烩，看不出文件归属哪个功能。
• Domain-Based：按业务能力分组，常被误称 DDD——真正的 DDD 是建模纪律，涉及限界上下文、聚合等，这里只是按业务域映射团队边界，适合大规模多团队产品。
• Atomic Design：UI 组件架构而非应用架构，按 atoms、molecules、organisms、templates、pages 分层，适合做跨应用共享的组件库。
• Duck：把 reducer 的 actions、types、逻辑放同一文件夹，Redux Toolkit 的 createSlice 已吸收此思路，多见于老代码库。
• Monorepo：apps/mobile 与 apps/web 共享 packages/ 下的业务逻辑、组件和工具，避免双端逻辑漂移；可用 Yarn Workspaces 或 Lerna 起步，规模大了配 Nx 或 Turborepo。
• Modular：常被叫 "Micro-Frontend"，但 RN 没有 Web 那种运行时组合能力，只有一个 JS bundle；真正接近的是 Re.Pack 或原生 super-app 插件架构，多数团队实际只是更严格的 feature/domain 组织。
选型框架看三点：项目规模与复杂度、团队人数与分工、增长预期。示例路径：小团队从 Feature-Based 起步，到约 100 人引入 Monorepo，再往后按业务域迁移到 Domain-Based。早期不做这些思考不算错，但营收和用户增长出现后，公司通常会招资深工程师来给从未为扩展设计的代码补架构。
#开发者 #工具 #ReactNative #移动开发 #项目架构 #Monorepo #DDD #Redux #前端架构
@DevToolboxHub