域·质量属性
GD-M
域组基础进阶高级14 节点
§1组简介
组目录:本质层方法论层技术实践层域·概念与需求域·架构设计域·实现与构造域·测试域·部署域·运维域·演化与弃用域·质量属性域·团队与康威域·方法论主干域·跨域横切·质量属性横切·技术债横切·团队与康威案例层
本组 14 个节点，类型为 域组，域 M，覆盖阶段 基础 / 进阶 / 高级。
§2成员节点目录
| 节点 ID | 名称 | 层/来源 | 阶段 | 简介 |
|---|---|---|---|---|
| ESS-M-01 | 可维护性本质 | 本质 essence | 基础 | 可维护性不是单一属性，而是被拆成三根支柱，各有明确所指。可运维性让组织能省力地把系统稳定跑下去：开放关键指标供监控采集、不让任何一台机器成为必需、给出清晰文档与可预期的操作模型、提供合理默认值同时允许覆盖、在恰当处自动修复也保留人工接管。简单性要求采用为人熟知且前后一致的模式与结构，把不必要复杂度挡在外面，使新加入的人也能读懂系统。可演化性要求系统在需求变动时便于调整与扩展，包括事先未预料到的使用场景。三者共同的动机是成本结构：软件的主要开销落在持续维护而非初次开发，涵盖修缺陷、保持运行、调查失效、适配新平台、支持新场景、偿还技术债与添加功能； |
| ESS-M-02 | 可演化性与可扩展性 | 本质 essence | 进阶 | 可伸缩性之所以不能简化为一个标签，是因为它由两步组成：先刻画负载，再评估资源与性能的关系。刻画负载通常取某项吞吐量指标，比如每秒请求数、每天新增数据量或每小时结账次数，有时取峰值如同时在线人数；读写比例、缓存命中率、单用户数据项数等统计特征同样会改变访问模式与伸缩要求。第二步从两个角度提问：资源不变时加大负载，性能如何变化；希望性能不变时，要增加多少资源。常见的经验是资源翻倍换两倍负载，即线性伸缩，偶尔因规模经济或峰值更均匀而优于线性，但更常见的是成本增长快于线性——数据量大时，同样大小的写入也要做更多工作。 |
| ESS-M-03 | 性能效率本质 | 本质 essence | 基础 | 性能效率的可操作含义是：起点为某个具体事件抵达系统，终点为系统在给定的时间或资源预算内交出响应。因此一条可用的性能陈述至少要同时说清三件事——负载以什么形态、以多快的节奏到来；允许多长的等待或多大的资源开销；以及用什么量去判定是否达标。反例是把性能写成「系统应当很快」，它既没指明哪类事件，也没指明并发规模与度量口径，因而无法验证也无法验收。另一处容易被忽略的边界是：性能要求即便从未被明文写出，也客观存在并被使用者感知，例如按键后整整一秒才显示字符的编辑器会被直接判定为不可用；所以缺省的性能期望应被主动补写成场景。 |
| ESS-M-04 | 可靠性与可用性 | 本质 essence | 进阶 | 可靠性用一句话概括就是即使出了问题也能继续正确工作，其外延由用户期望给出：功能符合预期、允许用户犯错或以非预期方式使用、在预期负载与数据量下性能足够、能挡住未授权访问与滥用。定义的关键动作是把故障与失效分开：故障指系统的某个部分停止正常工作，失效指整个系统不再提供所需服务、即未达到服务级别目标。二者常被混为一谈，其实只是观察层次不同——单块硬盘停转对只有一块盘的机器就是失效，对多盘系统只是一项故障，只要别处还有副本，系统就可能容忍它。可靠性因此以服务级别目标来衡量。容错总是针对特定类型与数量的故障而言，无法容忍某部分故障的部分称为单点故障； |
| ESS-M-05 | 质量属性不可直接测量 | 本质 essence | 基础 | 质量属性的界定要点有三：其一，它描述的不是系统做什么，而是干系人对系统效用的满意程度；其二，它必须能被量化观察或验证，否则无法进入验收；其三，它总是附着在功能之上——同一段功能可以配不同的响应快慢、允许出错频次与上手难度等标注。因此质量属性不是功能的替代品，而是对功能的约束与修饰：脱离功能谈质量属性会失去落点，只谈功能不谈质量属性则无法判断系统是否真的好用。可量化这一条是硬约束，不可量化的质量诉求既无法判定也无法验收，只能停留在主观评价层面。 |
| MTH-M-01 | 质量属性战术映射方法 | 方法论 methodology | 进阶 | 战术是影响某项质量属性响应能否达成的设计决策，它直接作用于系统对某类刺激的反应。与模式的区别在于作用范围：战术瞄准单项质量属性的响应，模式描述的是特定语境下反复出现的设计问题及其被验证过的解法，用元素的角色、职责、关系与协作方式来表述。适用边界在于：一条设计决策如果说不清它针对哪类刺激、要改变哪项响应，就还不构成战术，只是普通的实现选择。把每项质量属性目标映射到一组可组合的战术，再由战术组合成架构策略、打包为模式，这一映射的作用是把抽象的质量目标转化为具体、可评审的设计动作。战术位于模式与单条质量属性之间：模式是面向完整问题的打包方案，粒度大、语境强； |
| MTH-M-02 | 可修改性战术应用 | 方法论 methodology | 进阶 | 可修改性指系统在需求或环境变化时，以可接受的代价完成修改的能力。其方法以耦合、内聚与成本动因为依据应用一组战术：推迟绑定时间、局部化变更、防止涟漪效应，使修改集中在局部、缩小受影响模块数与回归风险，从而降低变更成本。判据不是代码是否整齐，而是「改动一个模块时，有多少其它模块必须随之改动」。影响范围由模块之间的相互牵连程度与模块内部职责的聚合程度共同决定：牵连越高、聚合越低，一次改动波及的范围就越广。变更成本等于改动本身的成本加上因耦合被牵连的其它模块的成本，故减少后者往往比减少前者更能显著降低总成本。 |
| MTH-M-03 | 可用性战术应用 | 方法论 methodology | 进阶 | 可用性讨论的起点是把两个词分清：失效指系统不再按规格交付服务，且这一情况能被参与者观察到；故障指可能导致失效的潜在原因。二者是因果而非同义关系，一组故障有可能引发失效，也可能被挡住而不引发。这个区分支撑了整章的策略：战术的作用就是阻止故障演化为失效，或者在无法阻止时把影响限定住，并让修复成为可能。由此也可以解释为什么没有宕机不能证明架构可用——故障可能一直在发生，只是尚未被观察到。围绕这个目标，可用性战术按目的分三类：检测故障、从故障中恢复、预防故障。 |
| MTH-M-04 | 质量模型应用方法 | 方法论 methodology | 进阶 | 以标准化的质量模型（由质量特性与子特性构成的框架）为共同参照，把分散的质量关切组织为可规定、可测量、可评价的维度，并据此在需求、设计与评价之间建立一致的映射。 |
| MTH-M-05 | 可维护性评估方法 | 方法论 methodology | 高级 | 沿可维护性的子特性组织证据，结合结构度量、变更历史与维护过程指标，对系统「修改得有多有效、多高效」做出可比较判断，并据此定位需优先治理的结构问题。 |
| MTH-M-06 | 质量属性权衡决策方法 | 方法论 methodology | 高级 | 面对相互牵制的质量属性，先以场景明确各属性目标与可接受边界，再识别同时影响多个属性的权衡点，通过显式比较与优先级排序做出可解释、可复核、可撤销的决策。质量属性很少能同时最优：为提升性能引入缓存会加剧一致性难度，为增强安全增加校验会拖慢响应，为提高可用性增加冗余会抬高成本与复杂度，为改善可维护性增加抽象会消耗运行期资源。因此架构设计的本质不是让每个属性都最大化，而是在给定语境下选择一组彼此相容的目标，并对冲突处做出有依据的取舍。 |
| TEC-M-01 | 质量模型工具化 | 技术实践 technology | 进阶 | 把 SQuaRE 系列标准的质量特性与子特性框架落为可操作的检查表、需求模板与评价工具，使质量关切在需求、设计与评价之间以同一坐标被规定、测量与比较。 |
| TEC-M-02 | 可维护性量化 | 技术实践 technology | 高级 | 把可维护性与技术债转写为可计算指标：以修复违规的成本估计债务本金、按对可维护性的影响折算利息，沿质量子特性组织规则与评分，使变更成本可比较、可追踪。 |
| TEC-M-03 | 可修改性战术实现 | 技术实践 technology | 进阶 | 可修改性战术的实现，指把推迟绑定时间、局部化变更与防止涟漪效应这三类设计决策落到具体结构机制上，包括接口与间接层、易变决策的封装位置、依赖方向约束与依赖反转，目标是缩小每一次修改的影响半径。第八章节把这些手段归入三个抽屉。一是提升内聚，做法是拆分职责过杂的模块、把散落各处的同类职责重新归拢。二是降低耦合，做法是加壳封装、插入居间者、把公共能力抽成共享服务、约束模块可见与可依赖的范围。三是推迟绑定，做法涵盖构件替换、编译期参数化、切面、配置期赋值、资源文件、运行期发现、参数解释、共享仓库与多态分派。 |
§3组内关系图
前置依赖实现依据推导案例印证对比冲突
§4学习路径提示
本组内存在 3 条前置依赖边（prerequisite），推荐先掌握前置知识点，再进入依赖它的节点。
推荐阅读顺序（拓扑序）
性能效率本质 → 可修改性战术应用 → 可用性战术应用 → 可维护性评估方法 → 质量属性权衡决策方法 → 质量模型工具化 → 可维护性量化 → 可修改性战术实现 → 可靠性与可用性 → 质量模型应用方法 → 质量属性战术映射方法 → 质量属性不可直接测量 → 可维护性本质 → 可演化性与可扩展性
- 可维护性本质 → 可演化性与可扩展性可修改能力是可演化性的先决条件
- 质量属性不可直接测量 → 可维护性本质属性可操作化是可评估可维护性的前提
- 质量属性权衡决策方法 → 质量属性战术映射方法战术映射是权衡决策的前置输入