DDD项目文件夹结构选型：两种组织方式的优劣与建议

一、按类型层级划分的结构（Type-Based） #

你当前采用的是按文件类型分组的结构，示例如下：

entities
 - UserEntity.ts
 - OrgEntity.ts
repositories
 - UserRepo.ts
services
  - (and so on)

优缺点 #

• 优点：
  • 同类文件集中存放，快速定位特定类型资源，比如找所有实体直接进entities目录
  • 结构直观，新手易上手，契合传统分层开发思维
  • 跨领域通用组件复用方便，比如通用Repository基类可统一放在repositories下
• 缺点：
  • 项目规模扩大后，单个目录下文件会泛滥，比如entities可能堆积几十个不同领域的实体，查找特定领域实体效率低
  • 同一业务逻辑的代码分散在多个目录，梳理完整业务流程需要在entities、repositories、services间来回跳转，维护成本飙升
  • 容易弱化领域边界，开发者可能随意跨领域调用，破坏DDD聚合的封装性

适用场景 #

• 小型DDD项目，领域数量少，每个领域的文件量级小
• 团队成员对DDD理解较浅，需要从简单结构过渡
• 项目存在大量跨领域复用的通用组件，需要集中管理

二、按领域聚合划分的结构（Aggregate-Based） #

另一种是按DDD聚合根分组的结构，示例如下：

users
 - UserEntity.ts
 - UserRepo.ts
 - UserService.ts
orgs
 - (anything belongs to Org)

优缺点 #

• 优点：
  • 单个聚合的所有相关代码集中在一起，查看某领域业务逻辑时无需跨目录，上下文清晰
  • 天然强化领域边界，开发者难以随意跨聚合调用，更符合DDD的核心设计理念
  • 扩展性强，新增领域聚合时直接新增对应目录即可，不会干扰现有结构
  • 便于团队分工，成员可负责特定聚合，职责划分明确
• 缺点：
  • 查找特定类型文件（比如所有Repository）需要遍历多个聚合目录，不如类型结构直接
  • 通用组件需要单独抽离到shared或common目录，初期需要额外做通用模块的设计
  • 对团队DDD能力要求较高，需准确识别聚合边界才能合理划分目录

适用场景 #

• 中大型DDD项目，领域聚合多，业务逻辑复杂
• 团队成员熟悉DDD理念，能准确界定聚合边界
• 项目需要长期迭代维护，重视领域边界清晰和业务上下文的连贯性

三、选型建议 #

1. 新项目评估：
   • 若项目规模小、团队DDD经验不足，先采用类型结构快速启动，待业务扩展、团队对DDD理解加深后，逐步重构为聚合结构
   • 若项目是中大型、业务复杂度高，直接采用聚合结构，从根源上保障领域边界清晰
2. 现有项目重构：
   • 若当前类型结构已出现维护困难（如文件过多、跨目录跳转频繁），可逐步迁移到聚合结构，优先从核心业务聚合开始调整
3. 混合模式可选：
   • 核心业务采用聚合结构，通用组件（如通用实体基类、工具类）单独放在shared目录集中管理，兼顾聚合结构的上下文清晰和类型结构的复用便捷

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