域·架构设计
GD-G
域组基础进阶高级17 节点
§1组简介
组目录:本质层方法论层技术实践层域·概念与需求域·架构设计域·实现与构造域·测试域·部署域·运维域·演化与弃用域·质量属性域·团队与康威域·方法论主干域·跨域横切·质量属性横切·技术债横切·团队与康威案例层
本组 17 个节点，类型为 域组，域 G，覆盖阶段 基础 / 进阶 / 高级。
§2成员节点目录
| 节点 ID | 名称 | 层/来源 | 阶段 | 简介 |
|---|---|---|---|---|
| ESS-G-01 | 关注点分离 | 本质 essence | 基础 | 按不同关注点维度把系统分解为可独立处理的部分，使每部分只承担一组相关职责。它是分解问题的元原则，为模块化与分层提供依据，成败取决于维度是否真正正交。若干流派在细节上各异，却共享同一目标：把软件切成层，且至少一层承载业务规则、另一层承载用户与系统接口。分离到位后应表现出五项可观察性质：不依赖某个功能齐备的库；业务规则脱离界面与库即可测试；界面可整体替换而其余部分不动；持久化产品可更换而规则不被绑定；业务规则对外部世界的接口一无所知。因此验收标准不是画了几条线，而是替换任意一个外部元素时改动是否被限制在边界外侧。 |
| ESS-G-02 | 依赖倒置与依赖规则 | 本质 essence | 进阶 | 稳定策略不应依赖易变细节：通过抽象使高层策略与低层实现都依赖抽象，让源码依赖方向指向更稳定、更抽象的一端。其含义不是高层依赖低层再调用回来，而是双方都依赖一个由稳定侧拥有的抽象——高层定义它需要的能力，低层去实现它。配套的依赖规则要求源码依赖只能由外层指向内层，禁止反向，由此形成单向依赖图，稳定且抽象的核心不被细节牵引，边界可替换，实现细节可独立演化。但把它当铁律并不现实：系统必须依赖大量具体设施，有些具体类型改动极罕见且受严格控制，对它们的依赖不该也无法回避。可容忍的是一层稳定背景，例如操作系统与平台设施；要避开的是团队正在活跃开发、频繁变动的模块。 |
| ESS-G-03 | 边界与接口隔离 | 本质 essence | 进阶 | 在模块、服务与层之间显式划定边界，并让跨边界交互仅通过窄而稳定的接口进行，把内部实现与外部契约隔离开。边界决定变更传播范围与理解成本。它要求把跨边界交互收敛为显式承诺。 |
| ESS-G-07 | 架构描述与对应关系 | 本质 essence | 进阶 | 架构本身是不可见的抽象，表达架构的工件称为架构描述（AD）。AD 由描述元素、模型种类与对应关系构成，并以对应的强制规则约束视图内部及视图之间的一致性、可追溯与组合，使多份面向不同关注点的局部表达汇成对同一架构的统一、可校验的整体。 |
| MTH-G-05 | 架构文档化方法 | 方法论 methodology | 进阶 | 以「文档化相关视图，再文档化适用于多个视图的信息」为组织原则的架构文档化方法：先按预期用途与干系人关注选择视图，再表达每个视图的「如何组织、架构是什么、为何如此」，并以跨视图信息与一致性校验避免文档过载与失真。 |
| MTH-G-06 | 效用树与敏感点权衡点分析 | 方法论 methodology | 高级 | 把质量属性自顶向下细化为带刺激与响应度量的场景并排序，形成效用树；再沿树把架构决策逐条映射到场景上，标出对单一属性响应影响显著者与同时反向影响多项者，并归纳风险主题。它把笼统的质量目标变成可探测、可排序、可聚焦的风险清单。效用树的结构可以逐层读出：根节点表示系统整体的好，其下一层列出该系统必须呈现的主要质量属性，再下一层把每个属性细化为与本系统相关的具体侧面，叶片位置放的是以刺激与响应度量写成的场景。它之所以被设计成树而非清单，是因为自顶向下逐层收窄能把笼统的属性名逼到可判定的场景，避免停留在可修改、高吞吐这类无法验收的层面。 |
| TEC-G-01 | AWS 良好架构框架 | 技术实践 technology | 进阶 | AWS 发布的云架构最佳实践对照框架，以运营卓越、安全、可靠性、性能效率、成本优化、可持续性六大支柱组织设计原则与评审问题，用于一致地度量工作负载与最佳实践的偏差。 |
| TEC-G-02 | GCP 良好架构框架 | 技术实践 technology | 进阶 | Google Cloud 发布的云架构建议框架，以运营卓越、安全隐私与合规、可靠性、成本优化、性能优化、可持续性六大支柱及 AI/ML、金融等跨支柱视角，指导设计安全、高效、韧性、高性能且可持续的云拓扑。 |
| TEC-G-03 | Azure 架构中心 | 技术实践 technology | 基础 | Microsoft 维护的 Azure 架构中心，汇集云架构风格目录（N 层、微服务、事件驱动等，含适用性、收益与挑战）与安全部署实践，指导按业务驱动与非功能需求选择风格并安全发布变更。 |
| TEC-G-04 | ThoughtWorks 技术雷达 | 技术实践 technology | 进阶 | Thoughtworks 技术咨询委员会每年发布两次的技术快照，以技术/方法条目（blip）经四象限与四环（Adopt/Trial/Assess/Caution）组织，表达对技术采用程度的带观点推荐，并明确不追求全面、不接受厂商付费影响。 |
| ESS-G-04 | 模块化与分解 | 本质 essence | 基础 | 模块化与分解指的是把整体切成若干能够各自独立运转的较小单元，使每个单元的扩容、部署与故障处置不再被其余部分牵连。它被视为可伸缩性最通用的一条做法，因为服务化、数据分片、流式处理以及节点各自持有本地资源的形态，底层走的都是同一条思路。定义的重心并不落在切这个动作上：真正的判定标准是切完之后各单元能否在负载增长时被单独放大。哪些职责应当留在一起、哪些应当分开，并没有通用答案，因此分解的边界是相对的，取决于当前负载形态与团队条件，而不是可以照抄的结构模板。切得过细同样会反噬。 判断边界是否合理，有一个可操作的观察点：某单元能否在不牵动邻单元的前提下完成一次容量调整或一次故障切换。 |
| ESS-G-05 | 架构风格 | 本质 essence | 进阶 | 定义一类系统结构组织方式的模式：规定该系统实例中可用的组件与连接件词汇表，以及它们的组合约束，从而约束设计空间并带来一组可预期的属性。 |
| ESS-G-06 | 视图与视角 | 本质 essence | 进阶 | 按不同干系人的关注点，从特定角度表达系统架构的概念结构；视角是一类视图的构造与解释约定，视图则是按某个视角约定所作的具体表达。 |
| MTH-G-01 | 架构决策记录 | 方法论 methodology | 基础 | 把每个架构上重要的决策记录为短文本文件（含上下文、决策、状态与后果），使决策依据、取舍与被否决的备选可被追溯、复核与取代，而非散落在会议记录与个人记忆中。 |
| MTH-G-02 | 质量属性场景与ATAM | 方法论 methodology | 进阶 | 质量属性场景是把「快」「稳」「可改」这类说法转成可验收需求的固定格式，共六个位置：谁发出刺激、刺激是什么、处于什么环境、作用于哪个制品、系统应给出什么响应、响应用什么度量判定。它的价值在于绕开两个常见麻烦——属性定义本身不可测，以及同一现象被不同属性社群各自认领。两个补充限定：六个位置在早期常被省略，但知道它们存在会迫使设计者逐项确认是否真的不相关；响应度量是整条场景能否被验收的关键，缺了它场景就退化为愿望。因此场景既不是模板填空的产物，也不是需求的替代物，而是把质量诉求推到可判定状态的载体。 |
| MTH-G-03 | 架构风格选择方法 | 方法论 methodology | 高级 | 架构风格可理解为对一类系统组织方式的命名与约定：风格固定了可用构件的种类、连接方式的种类，以及二者允许如何拼装。选型方法则以质量属性场景为判据，把候选风格的构件—连接件约束逐项映射为属性收益与代价，在具体子域上择优，而非寻找普适最优。其要点有三：其一，风格的本质是约束集合，符合约束才带来特定属性，而约束一旦采纳，包里每项战术的收益与副作用同时生效，且通常不只作用于一项质量属性；其二，同一风格在不同子域、不同负载形态与不同规模下，收益与代价可能整体反转，故不存在放之四海皆准的答案，只能就事论事地评估；其三，落锤前必须把代价显性化，说清放松哪条约束换取哪项属性。 |
| MTH-G-04 | 领域驱动战略设计 | 方法论 methodology | 高级 | 以限界上下文显式划定模型适用边界、以通用语言在单个上下文内统一团队与代码的表达，并通过上下文映射管理跨上下文关系的领域建模战略方法。 |
§3组内关系图
前置依赖实现依据推导案例印证对比冲突
§4学习路径提示
本组内存在 6 条前置依赖边（prerequisite），推荐先掌握前置知识点，再进入依赖它的节点。
推荐阅读顺序（拓扑序）
关注点分离 → 模块化与分解 → 领域驱动战略设计 → 架构文档化方法 → 效用树与敏感点权衡点分析 → AWS 良好架构框架 → GCP 良好架构框架 → Azure 架构中心 → ThoughtWorks 技术雷达 → 架构风格 → 边界与接口隔离 → 视图与视角 → 质量属性场景与ATAM → 依赖倒置与依赖规则 → 架构描述与对应关系 → 架构决策记录 → 架构风格选择方法
- 边界与接口隔离 → 依赖倒置与依赖规则先划定边界，才能约束依赖方向
- 视图与视角 → 架构描述与对应关系视图与视角概念是理解架构描述构成与对应关系的前提
- 关注点分离 → 架构风格关注点分离是理解与选择架构风格的认知基础
- 关注点分离 → 视图与视角关注点分离是视图与视角划分的基础
- 质量属性场景与ATAM → 架构决策记录识别敏感点与权衡点是记录架构决策的前提
- 质量属性场景与ATAM → 架构风格选择方法质量属性场景与评估是风格权衡选型的前置分析