ddd-architecture-selector

DDD 架构选择器

架构选择决策指南，根据项目背景评估 5 种 DDD 架构模式（分层架构、洋葱架构、六边形架构、整洁架构、COLA），涵盖团队规模、业务复杂度、技术栈、基础设施变更频率和生态偏好。

工作流

步骤 1：收集项目背景

• 团队规模和 DDD 经验水平
• 业务复杂度（简单 CRUD／中等／高）
• 技术栈（Spring Boot／Go／Node.js／.NET／Python）
• 基础设施变更频率（低／中／高）
• 多入口需求（REST + CLI + MQ + gRPC？）
• 测试覆盖率要求（单元／集成／E2E）
• 生态偏好（中国社区／国际社区）

步骤 2：运行决策矩阵

• 从 7 个或更多维度比较 5 种架构

步骤 3：应用决策树

• 复杂度 → 团队规模 → 技术栈 → 推荐架构

步骤 4：推荐 CQRS 级别

• L0：无，L1：模型分离，L2：数据库分离，L3：事件溯源

步骤 5：划分领域类型

• 核心／通用／支撑 → 为不同领域应用不同架构

步骤 6：建议微服务拆分

• 一个 BC → 一个服务，并提供合并／拆分规则

步骤 7：指向特定架构技能

• 链接到详细的实现指南

适用场景（及不适用场景）

✅ 适用场景	❌ 不适用场景
启动新项目：需要确定架构	架构已经确定 → 直接使用对应技能
比较多种 DDD 架构	只需学习 DDD → 使用 ddd-architecture-awesome
团队不确定哪种方案最合适	需要评估现有项目的架构 → 使用 ddd-architecture-evaluator
规划微服务拆分策略	选定架构后需要领域建模 → 使用 ddd-domain-designer
评估 CQRS 的必要性	评估非 DDD 项目（可考虑标准 MVC）
中国企业团队进行技术决策	不需要 DDD 的简单 CRUD → 使用标准 MVC
团队规模／DDD 成熟度未知	需要审查现有 DDD 代码 → 使用 ddd-code-reviewer

适用边界

类别	描述	替代方案
✅ 负责	新项目架构选择（5 种 DDD 架构）	—
✅ 负责	为迁移决策比较架构	—
✅ 负责	评估 CQRS / Event Sourcing 的必要性	—
✅ 负责	领域分类（核心 / 通用 / 支撑）	—
✅ 负责	根据限界上下文拆分微服务	—
✅ 负责	团队规模 → 架构映射	—
⚠️ 需要	基本项目背景：团队规模、业务复杂度、技术栈	—
⚠️ 需要	分类时需要领域专家或产品负责人参与	—
❌ 不在范围内	已经确定架构——请勿使用此技能	ddd-architecture-layered / ddd-architecture-onion / ddd-architecture-hexagonal / ddd-architecture-clean / ddd-architecture-cola（分别使用以下命令安装：npx skills add full-stack-skills/ddd-skills --skill <name>）
❌ 不在范围内	只需学习 DDD 和相关概念——不应使用此技能	ddd-architecture-awesome（安装命令：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-awesome）
❌ 不在范围内	评估现有架构的健康度和质量——请勿使用	ddd-architecture-evaluator（安装命令：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-evaluator）
❌ 不在范围内	选择架构后进行领域建模 / 聚合设计——请勿使用	ddd-domain-designer（安装命令：npx skills add full-stack-skills/ddd-skills --skill ddd-domain-designer）
❌ 不在范围内	审查代码是否符合 DDD——请勿使用此技能	ddd-code-reviewer（安装命令：npx skills add full-stack-skills/ddd-skills --skill ddd-code-reviewer）
❌ 不在范围内	非 DDD / 标准 MVC 项目——请勿使用此技能	使用标准 MVC 指南（非 DDD 技能）

适用对象

此技能面向：后端开发人员（实施 DDD 架构）、软件架构师（评估和选择模式）、技术负责人（审查团队实施情况）和 DDD 初学者（学习领域驱动设计基础知识）。

规则

1. 架构选择必须至少评估 5 个维度。
2. 切勿默认推荐 Event Sourcing——仅在 L2 CQRS 成功后推荐。
3. 团队规模和领域复杂度必须是首要选择因素。

5 种架构决策矩阵

维度	Layered	Onion	Hexagonal	Clean	COLA
学习成本	★☆☆	★★★	★★★	★★★	★★☆
业务复杂度适配度	★☆☆	★★★	★★★	★★★	★★★
CRUD 效率	★★★	★☆☆	★☆☆	★☆☆	★★☆
基础设施可替换性	★☆☆	★★★	★★★	★★★	★★☆
测试友好度	★☆☆	★★★	★★★	★★★	★★★
中文社区	★★★	★☆☆	★☆☆	★☆☆	★★★
代码生成支持	良好	较差	较差	较差	极佳
模块物理隔离	低	中	中	高	高
演进路径清晰度	★☆☆	★★★	★★★	★★★	★★★
适配团队规模	1-5	5-15	5-15	15-50	5-50
起源	Martin Fowler	Jeffrey Palermo (2008)	Alistair Cockburn (2005)	Robert C. Martin (2012)	Alibaba (2018)

架构	最适合	应避免的情况
Layered	简单 CRUD、小团队、传统 MVC 迁移	复杂业务规则、基础设施频繁变更
Onion	高测试覆盖率、基础设施不断变化	CRUD 密集型应用、没有抽象经验的团队
Hexagonal	多入口系统、微服务标准化	简单的单入口 CRUD、快速原型
Clean	大型企业系统、严格的物理隔离	小团队（<5 人）、快速 MVP 迭代
COLA	中国 Spring Boot 生态、工程规范	非 Java 技术栈、国际团队

3 步决策树

步骤 1：评估业务复杂度

Business Complexity?
│
├── Simple CRUD (80%+ CRUD operations)
│   └── Planning DDD adoption in future?
│       ├── No  → LAYERED ARCHITECTURE
│       └── Yes → COLA Simplified (single module)
│
├── Moderate (core business logic with rules)
│   ├── Chinese ecosystem / Spring Boot + MyBatis?   → COLA
│   ├── Value domain layer purity most?               → HEXAGONAL
│   ├── Multi-entry system (REST + CLI + MQ)?         → HEXAGONAL
│   ├── Infrastructure changes often?                 → HEXAGONAL / ONION
│   └── .NET / Python stack?                          → ONION
│
└── High (multiple BCs, microservices)
    ├── Enterprise / international team?              → CLEAN ARCHITECTURE
    ├── Chinese enterprise, per-service standards?     → COLA (multi-module)
    ├── Mixed tech stack per service?                 → HEXAGONAL per service
    └── Need microservice + standard per module?      → COLA + HEXAGONAL hybrid

步骤 2：匹配团队规模

团队规模	推荐架构	理由
1-5	分层架构或简化版 COLA	仪式最少，交付最快
5-15	六边形 / 洋葱 / COLA（单模块）	平衡抽象与生产力
15-50	整洁架构 / COLA（多模块）	物理隔离，支持团队并行工作
50+	微服务 + 各服务采用六边形架构	团队自治，独立部署

演进路径：团队壮大 → 逐步升级架构：1-5（分层架构）→ 5-15（六边形）→ 15-50（整洁架构/COLA）→ 50+（微服务+六边形架构）。

步骤 3：最终建议

如果你使用……	那么选择……	原因
Spring Boot + MyBatis + 中国团队	COLA	生态契合，有中文文档和脚手架
多入口（REST + CLI + MQ + gRPC）	六边形架构	适配器模式可处理多个入口
严格要求模块物理隔离的大型企业	整洁架构	强制隔离 Entity → UseCase → Adapter
基础设施经常变更（DB、MQ 替换）	六边形架构 或 洋葱架构	端口/适配器使替换轻而易举
快速原型 → 之后演进为 DDD	分层架构 → 升级	启动成本最低，演进路径清晰
业务规则复杂 + TDD	六边形架构	可独立测试领域层
团队刚接触 DDD，逐步采用	分层架构	最接近传统三层架构，学习曲线最平缓
微服务内部架构标准	每个服务采用 六边形架构 + COLA	端口隔离 + 工程标准
读多、查询复杂	CQRS L2	读写分离，独立优化
需要完整审计轨迹	事件溯源（L3）	事件流天然支持审计

领域划分 + 微服务拆分

领域分类（核心域 / 通用域 / 支撑域）

领域类型	投入策略	架构建议	示例
核心域（核心域）	最大投入，自主构建	使用丰富领域模型的六边形架构 / 整洁架构 / COLA	订单管理、支付处理、定价引擎
通用域（通用域）	采购或复用开源方案	分层架构或现成 SaaS	身份验证、授权、通知
支撑域（支撑域）	外包或低优先级	分层架构或简单 CRUD	报表、管理仪表盘、数据导出

关键规则：不要将六边形架构或整洁架构用于通用域/支撑域——这会浪费精力。复杂架构只留给核心域。

微服务拆分规则

1. 默认：一个限界上下文 → 一个微服务
2. 拆分时机：部署节奏、扩缩容需求或团队归属不同
3. 合并时机：需要强事务一致性、上下文较小（开发时间 < 2 周）或由同一团队负责
4. 保守起步：服务数量尽量少，按需拆分（以实际需求为依据，而非预判）
5. 通信方式：最终一致性使用事件，强一致性使用 RPC（较少见）

CQRS 级别建议

级别	描述	成本	架构支持	适用场景
L0 — 无	单一模型，单一数据库	零	所有架构（默认）	简单 CRUD，无读写冲突
L1 — 模型分离	CommandService + QueryService，共享数据库	低	所有架构	读写差异中等
L2 — 数据库分离	命令数据库 + 读取数据库（ES/从库），通过事件同步	中	Hexagonal / Clean / COLA	读取量大，查询复杂
L3 — 事件溯源	事件存储 + 投影，完整事件重放	高	Hexagonal / Clean	审计追踪、时态查询、合规要求

建议：从 L0 开始，确认确有更高级别的需求。只有在采用 Hexagonal 或 Clean 架构以实现适当的端口隔离时，才应采用 L2 及更高级别。

架构技能导航

已选架构	下一项技能
Layered	ddd-architecture-layered（安装：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-layered）
Onion	ddd-architecture-onion（安装：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-onion）
Hexagonal	ddd-architecture-hexagonal（安装：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-hexagonal）
Clean	ddd-architecture-clean（安装：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-clean）
COLA	ddd-architecture-cola（安装：npx skills add full-stack-skills/ddd-skills --skill ddd-architecture-cola）

相关技能：ddd-cqrs-architecture / ddd-domain-designer / ddd-architecture-evaluator（均可通过 npx skills add full-stack-skills/ddd-skills --skill <name> 安装）

注意事项

参见 references/gotchas.md，了解 15 个易踩的坑。

常见问题

参见 references/faq.md，查看 15 个问答。

安全与保障

此技能纯属文档内容。它不会收集用户数据，不会访问外部服务或网络，也不包含可执行脚本。

参考资料

参见 references/，了解深入对比、微服务/领域、clean+DDD+hexagonal、ddd4j 分析、注意事项、常见问题、外部资源和 5 个案例研究。