架构与领域设计学习地图

学习目标

• 能解释“架构与领域设计学习地图”如何把 Clean Architecture 的依赖边界、DDD 的模型边界与三类扩展模式排成一条不混淆出处的学习路径
• 能逐项定位 架构边界、模型边界、战术建模、战略协作、读写分离扩展、端口与适配器扩展，并说明每个概念在当前来源边界内承担什么责任
• 能按 识别政策 → 划定模型 → 建立协作 → 选择扩展 → 用证据复核 推演“新建订单系统”，检查“每个概念都标明来源家族；平台学习顺序不能被写成任一本原著的章节顺序”
• 能注入“把 CQRS、事件溯源或六边形架构说成两本原书共同给出的统一方案”，依据来源标签、正式单元映射、边界图、决策轨迹与跨章节复习清单定位越界、撤销并用同一情境重放

为什么从“先学依赖方向，再学语言与模型边界，最后把 CQRS、事件溯源和六边形架构当作可选扩展逐一验收”开始

把 Clean Architecture 的依赖边界、DDD 的模型边界与三类扩展模式排成一条不混淆出处的学习路径。本页先画责任和依赖，再沿具体情境执行决策，最后主动制造一个边界违规；这种顺序把术语变成可以验证、推翻和恢复的设计合同。

“架构与领域设计学习地图”不是技术采购建议。它处理的是规则放在哪里、模型在哪个语境内成立、哪些变化可以被隔离，以及团队如何判断一条边界已经被穿透。最终功能可运行，只能证明快乐路径存在，不能证明结构允许安全演进。

来源、版次与课程边界

本页是平台原创学习地图，不对应任何一本书的原始章节。两本书限定主干范围，作者参考摘要和三篇原始文章负责核对可公开阅读的定义与扩展。

本专题不是某一本既有书的中文版，也不是把多位作者的文章拼成“原著章节”。课程主干分别取自 Eric Evans 的领域驱动设计体系与 Robert C. Martin 的整洁架构体系；CQRS、事件溯源和六边形架构始终标为扩展。以下链接承担不同事实责任：

• Pearson: Domain-Driven Design：核对 Eric Evans、第一版、出版信息与原书身份，不据此声称拥有全文
• Pearson: Clean Architecture：核对 Robert C. Martin、第一版、2017 年与正式目录范围
• Eric Evans: Domain-Driven Design Reference：核对 DDD 定义、模式摘要、增补范围与 CC 授权说明
• Robert C. Martin: The Clean Architecture：核对独立性目标、四层、依赖规则、跨边界控制流与简单边界数据
• Martin Fowler: CQRS：核对命令与查询模型分离、适用压力、复杂度和同步代价
• Martin Fowler: Event Sourcing：核对事件序列作为事实源、状态重建、重放和外部更新问题
• Alistair Cockburn: Hexagonal Architecture：核对内外边界、端口、适配器、无 UI/数据库运行与自动化测试动机

本页采用独立中文重写。能从公开全文或授权摘要核对的定义才作为来源事实；项目情境、交互实验、取舍表和练习答案均为本站教学设计。

核心概念与可观察责任

架构边界

用依赖方向保护业务政策，使界面、数据库和框架成为可以替换的细节；学习时先问谁知道谁，而不是先选技术栈。 在“新建订单系统”中，观察重点是每个概念都标明来源家族；平台学习顺序不能被写成任一本原著的章节顺序。

模型边界

用限界上下文声明一个模型和一套语言在哪个范围内有效；跨越范围时必须翻译，不能假设同名词天然同义。 在“遗留系统拆分”中，观察重点是来源标签、正式单元映射、边界图、决策轨迹与跨章节复习清单。

战术建模

实体、值对象、聚合、工厂和仓储服务于一个上下文内部的模型表达，不是全系统统一套用的类模板。 在“新建订单系统”中，观察重点是每个概念都标明来源家族；平台学习顺序不能被写成任一本原著的章节顺序。

战略协作

上下文映射描述团队与模型之间真实存在的关系，并据此选择共享、翻译、遵奉或分离，而非先画理想组织图。 在“遗留系统拆分”中，观察重点是来源标签、正式单元映射、边界图、决策轨迹与跨章节复习清单。

读写分离扩展

CQRS 与事件溯源解决不同问题，可以一起使用，也可以分别采用；它们不属于本专题两本书共有的原始目录。 在“新建订单系统”中，观察重点是每个概念都标明来源家族；平台学习顺序不能被写成任一本原著的章节顺序。

端口与适配器扩展

六边形架构把应用内部与外部技术隔开，以端口表达交互意图，以适配器完成协议转换，并强化可独立测试性。 在“遗留系统拆分”中，观察重点是来源标签、正式单元映射、边界图、决策轨迹与跨章节复习清单。

一条可执行的设计判断

本页采用以下判断链：先学依赖方向，再学语言与模型边界，最后把 CQRS、事件溯源和六边形架构当作可选扩展逐一验收。正常情况下必须持续保持“每个概念都标明来源家族；平台学习顺序不能被写成任一本原著的章节顺序”；反例“把 CQRS、事件溯源或六边形架构说成两本原书共同给出的统一方案”只改变一个关键条件，便于定位因果。

观察项	本页合同
最小正常情境	团队同时面对界面、数据库、计价语言和报表读模型选择
边界或迁移情境	旧库、共享术语与跨团队调用已经互相缠绕
必须保持	每个概念都标明来源家族；平台学习顺序不能被写成任一本原著的章节顺序
首要违规	把 CQRS、事件溯源或六边形架构说成两本原书共同给出的统一方案
验收证据	来源标签、正式单元映射、边界图、决策轨迹与跨章节复习清单

先预测，再操作三个本页实验

⚡分步1 / 3

1. 1
2. 2
3. 3

重置

实验一：边界与模型地图

操作前先预测“新建订单系统”里哪一侧拥有规则、哪一侧只是技术或协作细节。切换概念和情境后，检查“先学依赖方向，再学语言与模型边界，最后把 CQRS、事件溯源和六边形架构当作可选扩展逐一验收”是否仍能解释三块区域的责任。

Boundary model

架构与领域设计学习地图：边界与责任地图

把 Clean Architecture 的依赖边界、DDD 的模型边界与三类扩展模式排成一条不混淆出处的学习路径

切换最小情境

新建订单系统遗留系统拆分

定位正式概念

架构边界模型边界战术建模战略协作读写分离扩展端口与适配器扩展

learning-map · 当前观察

架构边界：团队同时面对界面、数据库、计价语言和报表读模型选择

区域 1依赖边界

政策在内，技术细节在外

↓

区域 2模型边界

语言与规则在上下文内保持一致

↓

区域 3扩展选择

按读写、历史与外部接口压力选模式

情境验收

先稳定业务政策与上下文，再为外部技术和扩展模式设边界

上一步播放下一步

易错边界与取舍

练习与答案

练习

问题 1：概念—边界—证据对照。 完成以下逐项核对：

1. 架构边界：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
2. 模型边界：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
3. 战术建模：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
4. 战略协作：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
5. 读写分离扩展：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
6. 端口与适配器扩展：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。

查看答案

对每个概念先确定它属于业务政策、模型协作还是外部技术，再画允许的依赖方向。用“团队同时面对界面、数据库、计价语言和报表读模型选择”建立正常基线，用“把 CQRS、事件溯源或六边形架构说成两本原书共同给出的统一方案”作为单一反例，最后从来源标签、正式单元映射、边界图、决策轨迹与跨章节复习清单中找第一处不一致。

问题 2：最小情境推演。 怎样验证“新建订单系统”没有靠最终功能碰巧通过？

查看答案

按 识别政策 → 划定模型 → 建立协作 → 选择扩展 → 用证据复核 保存每步状态，预期结果是“先稳定业务政策与上下文，再为外部技术和扩展模式设边界”。最终输出之外，还要逐步确认“每个概念都标明来源家族；平台学习顺序不能被写成任一本原著的章节顺序”；任一中间状态越界都应拒绝当前设计。

问题 3：替代方案与恢复。 注入“把 CQRS、事件溯源或六边形架构说成两本原书共同给出的统一方案”后，怎样比较修复与更简单方案？

查看答案

先保留故障前的来源标签、正式单元映射、边界图、决策轨迹与跨章节复习清单，再记录首个越界位置。分别实施最小修复和删除多余模式的方案，用同一个“旧库、共享术语与跨团队调用已经互相缠绕”重放；选择仍满足“先画真实依赖和上下文映射，再选择防腐层或端口适配器”且依赖更少的方案。

本页小结

• 架构与领域设计学习地图的核心判断是：先学依赖方向，再学语言与模型边界，最后把 CQRS、事件溯源和六边形架构当作可选扩展逐一验收。
• 正常路径以“先稳定业务政策与上下文，再为外部技术和扩展模式设边界”验收，不能只检查接口返回成功。
• 边界路径以“先画真实依赖和上下文映射，再选择防腐层或端口适配器”验收，并保存来源标签、正式单元映射、边界图、决策轨迹与跨章节复习清单。
• 如果“把 CQRS、事件溯源或六边形架构说成两本原书共同给出的统一方案”仍可静默通过，说明边界只是图示，没有成为可执行约束。