分层视图
按本质 / 方法论 / 技术实践三层浏览。
168 节点18 组364 边
§1本质 essence（51）
软件需求F · 概念与需求基础软件需求是「须被某物展现、以解决现实世界问题的属性」；它描述系统应满足的「什么（what）」而非「如何做（how）」，属于对解决方案的约束与对问题空间的陈述，而非设计决定。
干系人与需要F · 概念与需求基础干系人是对系统或其具备满足其需要与期望的特性拥有权利、份额、主张或利益的个人或组织；需要是对其 needs、wants、desires、expectations 与感知约束的引出，需求则由需要转化而来。
关注点分离G · 架构设计基础按不同关注点维度把系统分解为可独立处理的部分，使每部分只承担一组相关职责。它是分解问题的元原则，为模块化与分层提供依据，成败取决于维度是否真正正交。若干流派在细节上各异，却共享同一目标：把软件切成层，且至少一层承载业务规则、另一层承载用户与系统接口。分离到位后应表现出五项可观察性质：不依赖某个功能齐备的库；业务规则脱离界面与库即可测试；界面可整体替换而其余部分不动；持久化产品可更换而规则不被绑定；业务规则对外部世界的接口一无所知。因此验收标准不是画了几条线，而是替换任意一个外部元素时改动是否被限制在边界外侧。
依赖倒置与依赖规则G · 架构设计进阶稳定策略不应依赖易变细节：通过抽象使高层策略与低层实现都依赖抽象，让源码依赖方向指向更稳定、更抽象的一端。其含义不是高层依赖低层再调用回来，而是双方都依赖一个由稳定侧拥有的抽象——高层定义它需要的能力，低层去实现它。配套的依赖规则要求源码依赖只能由外层指向内层，禁止反向，由此形成单向依赖图，稳定且抽象的核心不被细节牵引，边界可替换，实现细节可独立演化。但把它当铁律并不现实：系统必须依赖大量具体设施，有些具体类型改动极罕见且受严格控制，对它们的依赖不该也无法回避。可容忍的是一层稳定背景，例如操作系统与平台设施；要避开的是团队正在活跃开发、频繁变动的模块。
边界与接口隔离G · 架构设计进阶在模块、服务与层之间显式划定边界，并让跨边界交互仅通过窄而稳定的接口进行，把内部实现与外部契约隔离开。边界决定变更传播范围与理解成本。它要求把跨边界交互收敛为显式承诺。
模块化与分解G · 架构设计基础模块化与分解指的是把整体切成若干能够各自独立运转的较小单元，使每个单元的扩容、部署与故障处置不再被其余部分牵连。它被视为可伸缩性最通用的一条做法，因为服务化、数据分片、流式处理以及节点各自持有本地资源的形态，底层走的都是同一条思路。定义的重心并不落在切这个动作上：真正的判定标准是切完之后各单元能否在负载增长时被单独放大。哪些职责应当留在一起、哪些应当分开，并没有通用答案，因此分解的边界是相对的，取决于当前负载形态与团队条件，而不是可以照抄的结构模板。切得过细同样会反噬。
判断边界是否合理，有一个可操作的观察点：某单元能否在不牵动邻单元的前提下完成一次容量调整或一次故障切换。
架构描述与对应关系G · 架构设计进阶架构本身是不可见的抽象，表达架构的工件称为架构描述（AD）。AD 由描述元素、模型种类与对应关系构成，并以对应的强制规则约束视图内部及视图之间的一致性、可追溯与组合，使多份面向不同关注点的局部表达汇成对同一架构的统一、可校验的整体。
信息隐藏H · 实现与构造进阶以「隐藏困难或可能变化的设计决策」作为模块分解判据：每个模块把一类易变决策封装为自己的秘密，接口只揭示尽量少的内部工作，使变更局部化。它规定的是划分依据与边界，而非模块的物理形态或大小。它是模块化有效性的根本来源之一。
内聚与耦合H · 实现与构造基础衡量模块划分质量的两个互补维度：内聚是模块内部元素隶属同一目标的程度，耦合是模块之间相互依赖的程度。目标是高内聚、低耦合，但二者只是启发式方向，并非有普适阈值的绝对指标。它衡量的是结构对变更的承载能力。
DRY 单一知识来源H · 实现与构造基础系统内每个知识点应有单一、无歧义、权威的表示，避免同一知识的多份副本各自漂移。它针对的是「知识重复」而非机械的代码重复，核心判据是：一处规则改变时，是否需要在多个位置同步修改。它衡量的是知识的归属是否清晰。
抽象泄漏H · 实现与构造高级所有非平凡抽象都会在不同程度上泄漏其底层实现：性能、故障与边界行为会穿透抽象边界，使用者被迫了解本应被隐藏的细节。这是抽象与封装固有的边界，而非实现缺陷。它要求设计者主动管理而非幻想消除这种穿透。
SOLID 职责划分与替换性H · 实现与构造进阶SOLID 是一组以职责划分与可替换性为判据的面向对象设计原则族：单一职责约束变更原因，开闭原则要求以扩展而非修改应对变化，里氏替换与接口隔离约束子类型与接口依赖，依赖倒置约束依赖方向。
设计模式与反模式H · 实现与构造进阶设计模式是对反复出现的设计问题所给的可复用解法模板，提供团队共同语言但不保证适用；反模式是初看合理却适得其反的常见解法，二者把设计经验的正反两面固化为可传承的知识。
测试作为验证与反馈机制本质I · 测试基础软件测试是以发现缺陷、评估质量为目的的活动集合；其本质不止于事后验证——它同时为开发提供持续反馈，使团队能在变更中保持正确性，因此测试是质量保障与支持演进的双重机制。
可测试性本质I · 测试基础可测试性说的是软件在多大程度上容易被证明有缺陷，而不是它究竟有没有缺陷。这一定位把它从测试活动的属性挪到了被测制品的属性上：同一支测试团队、同一套方法与工具，面对可测试性不同的两份系统，建立受控情境、读取内部状态、取得稳定反馈的代价会相差数量级。它由结构赋予，属于设计期就应当确定的性质，事后很难补齐；模块边界与依赖方向一旦改变，同一份功能代码所需的测试投入就会显著变化。由此可以推出它的两个容易混淆之处。其一，它衡量的是验证成本而非正确性本身，一个可测试性极差的系统也可能几乎没有缺陷，反过来测试写得很顺手也并不等于测试已经做够。
错误、缺陷与失效I · 测试进阶错误是人的行为产生的不正确结果，缺陷是制品中导致其偏离预期行为的瑕疵，失效是系统运行时表现出的与规定行为不一致；三者构成「错误→缺陷→失效」的因果链，是测试活动的认知对象。
测试的不可穷尽性I · 测试进阶测试只能证明缺陷的存在、无法证明其不存在；由于输入、状态与执行路径的组合空间在现实中不可穷尽，测试永远是抽样活动，因此测试策略的核心不是穷尽验证，而是基于风险选择最有价值的样本。
构建发布运行分离J · 部署基础软件交付须严格分离构建、发布、运行三阶段：构建把代码转换为可执行制品，发布把制品与当次配置合并为带唯一标识的不可变版本，运行只启动选定版本，且运行阶段不存在把改动写回构建的通道。
故障不可避免性与容错K · 运维基础可靠性与容错这组概念要先分清两个词。局部停止正常工作叫故障，例如一块盘坏掉、一台机器宕机，或所依赖的外部服务中断；整个系统不再满足对用户承诺的服务级别目标叫失效。两者其实是同一件事在不同观察层次上的称呼：只有一块盘的系统里，盘坏就是系统失效；而在多盘系统里，单盘坏掉只是整体视角下的一项故障，只要数据在别处还有副本，服务就能继续。由此得到容错的定义，即出现某些故障时仍能照常提供服务；反过来，某部分一旦出问题就必然升级为整体失效，这个部分就是单点故障。
定义里还隐含一层要求：容错总是相对于某个服务级别承诺而言的，离开承诺就无所谓失效。
软件演化定律L · 演化与弃用高级描述 E 型软件在持续演化中反复出现的规律：系统必须持续变更否则逐渐失效，而持续变更又使复杂度递增、质量下降，需要以自我调节与反馈治理。它把演化视为常态而非异常。它把演化确立为需要持续投入的常态过程。
变更成本随复杂度增长L · 演化与弃用进阶这条原则描述的是一种随规模累积的效应：项目小时代码可以短小漂亮，一旦持续扩张，结构就越来越难把握，每一次改动都要付出更多的理解与验证成本。这种状态被形象地称为复杂泥潭。它的定义要点是成本的位置发生了转移，复杂度并不直接表现为功能缺失或性能下降，而是表现为动手变慢、出错变多、预算与排期双双失守。因为结构越难让人推理，改动者就越容易漏看隐含前提、副作用与意料之外的相互干扰。所以简单性被提升为构建系统时的关键目标之一，它与可运维性、可演化性并列，共同构成可维护性的三个面向。
把这层定义再推进一步，可以看出复杂度并非某种可以一次性清除的杂质，而是一种随功能与规模必然增长的存量。
可维护性本质M · 横切·质量属性基础可维护性不是单一属性，而是被拆成三根支柱，各有明确所指。可运维性让组织能省力地把系统稳定跑下去：开放关键指标供监控采集、不让任何一台机器成为必需、给出清晰文档与可预期的操作模型、提供合理默认值同时允许覆盖、在恰当处自动修复也保留人工接管。简单性要求采用为人熟知且前后一致的模式与结构，把不必要复杂度挡在外面，使新加入的人也能读懂系统。可演化性要求系统在需求变动时便于调整与扩展，包括事先未预料到的使用场景。三者共同的动机是成本结构：软件的主要开销落在持续维护而非初次开发，涵盖修缺陷、保持运行、调查失效、适配新平台、支持新场景、偿还技术债与添加功能；
可演化性与可扩展性M · 横切·质量属性进阶可伸缩性之所以不能简化为一个标签，是因为它由两步组成：先刻画负载，再评估资源与性能的关系。刻画负载通常取某项吞吐量指标，比如每秒请求数、每天新增数据量或每小时结账次数，有时取峰值如同时在线人数；读写比例、缓存命中率、单用户数据项数等统计特征同样会改变访问模式与伸缩要求。第二步从两个角度提问：资源不变时加大负载，性能如何变化；希望性能不变时，要增加多少资源。常见的经验是资源翻倍换两倍负载，即线性伸缩，偶尔因规模经济或峰值更均匀而优于线性，但更常见的是成本增长快于线性——数据量大时，同样大小的写入也要做更多工作。
性能效率本质M · 横切·质量属性基础性能效率的可操作含义是：起点为某个具体事件抵达系统，终点为系统在给定的时间或资源预算内交出响应。因此一条可用的性能陈述至少要同时说清三件事——负载以什么形态、以多快的节奏到来；允许多长的等待或多大的资源开销；以及用什么量去判定是否达标。反例是把性能写成「系统应当很快」，它既没指明哪类事件，也没指明并发规模与度量口径，因而无法验证也无法验收。另一处容易被忽略的边界是：性能要求即便从未被明文写出，也客观存在并被使用者感知，例如按键后整整一秒才显示字符的编辑器会被直接判定为不可用；所以缺省的性能期望应被主动补写成场景。
可靠性与可用性M · 横切·质量属性进阶可靠性用一句话概括就是即使出了问题也能继续正确工作，其外延由用户期望给出：功能符合预期、允许用户犯错或以非预期方式使用、在预期负载与数据量下性能足够、能挡住未授权访问与滥用。定义的关键动作是把故障与失效分开：故障指系统的某个部分停止正常工作，失效指整个系统不再提供所需服务、即未达到服务级别目标。二者常被混为一谈，其实只是观察层次不同——单块硬盘停转对只有一块盘的机器就是失效，对多盘系统只是一项故障，只要别处还有副本，系统就可能容忍它。可靠性因此以服务级别目标来衡量。容错总是针对特定类型与数量的故障而言，无法容忍某部分故障的部分称为单点故障；
质量属性不可直接测量M · 横切·质量属性基础质量属性的界定要点有三：其一，它描述的不是系统做什么，而是干系人对系统效用的满意程度；其二，它必须能被量化观察或验证，否则无法进入验收；其三，它总是附着在功能之上——同一段功能可以配不同的响应快慢、允许出错频次与上手难度等标注。因此质量属性不是功能的替代品，而是对功能的约束与修饰：脱离功能谈质量属性会失去落点，只谈功能不谈质量属性则无法判断系统是否真的好用。可量化这一条是硬约束，不可量化的质量诉求既无法判定也无法验收，只能停留在主观评价层面。
康威定律N · 横切·团队与康威进阶设计系统的组织受沟通结构约束，其产出会复制该组织的沟通结构；系统架构与组织结构之间存在保结构的对应关系。它提示架构设计与组织设计必须协同。它把组织设计纳入架构决策的范畴。
本质复杂度与偶然复杂度O · 方法论主干/跨域综合高级这组区分由两个不对称的部分构成。本质复杂度是问题领域自身固有的概念结构，它来自所服务现实的概念关系本身，任何单一技术或管理手段都无法把它消除；偶然复杂度则是实现方式、工具局限与表示选择带来的负担，可以被工程手段持续削减。定义的关键在于归属判据而不是字面分类：某一部分难度究竟算哪一类，要看它是否随表示方式的改变而消失。这也解释了为什么这条区分是决策工具而非学术标签——它把该投问题理解还是该投工具改进变成一个可以追问的问题，使投入方向有据可依。判据可以写成一次替换实验：追问若换掉这项技术、改用另一种表示，问题的核心概念结构是否依然存在。仍然存在，说明这部分难度属于本质；
架构即权衡O · 方法论主干/跨域综合进阶把架构决策定义为取舍，依据是一个结构性事实：质量属性无法被孤立地达成，改善其中一项必然对其他项产生或正或负的影响。敏捷性与稳定性、安全性与性能、性能与可修改性、可靠性与成本，很难同时达到最优；再叠加预算、工期、遗留系统与团队能力等约束，架构本质上是在有限资源下的一组选择。由此推出的直接后果是最优架构这一提法失去意义——同一份设计在不同语境下会被判为恰当或失当，取决于该语境看重哪些属性、受哪些成本与合规约束。可操作的形态是把决策写成有向的代价与收益对照：选定某方案意味着接受某一组具体代价，并因此保住某一组具体收益。
权衡的不可消除性O · 方法论主干/跨域综合进阶任何设计都在有限资源与相互牵制的目标之间做选择，优化一个维度通常以牺牲另一个为代价；权衡不能被消除，只能被显式化、迁移，或在具体语境下选出更合适的落点。这一定义有三层含义需要分开。第一层是它的形式：取舍不是方案的缺陷，而是方案的定义本身，选定某条路径就等于同时接受了一组代价并保住了一组收益，因此描述一个架构决策的完整方式是成对陈述而不是单向宣称。第二层是它的来源：权衡之所以不可消除，一是资源有限，时间、算力、人力与注意力无法同时无上限地投向每个方向；二是目标之间存在结构性冲突，一方改善会直接牵制另一方，这层冲突不会因为预算变多而消失。
§2方法论 methodology（67）
需求工程过程F · 概念与需求进阶以业务或任务分析为起点，依次经干系人需要与需求定义、系统需求定义，并在各技术过程中嵌入需求活动，由需求管理贯穿的过程链；其信息项包括业务、干系人、系统与软件需求规格。
需求规格说明F · 概念与需求进阶把需求以明确、无歧义、可验证的方式文档化为信息项（如软件需求规格说明）的方法，要求单条需求具备必要、无歧义、单一、可行、可验证等特性，需求集具备一致、完整、可理解等特性。
质量属性场景与ATAMG · 架构设计进阶质量属性场景是把「快」「稳」「可改」这类说法转成可验收需求的固定格式，共六个位置：谁发出刺激、刺激是什么、处于什么环境、作用于哪个制品、系统应给出什么响应、响应用什么度量判定。它的价值在于绕开两个常见麻烦——属性定义本身不可测，以及同一现象被不同属性社群各自认领。两个补充限定：六个位置在早期常被省略，但知道它们存在会迫使设计者逐项确认是否真的不相关；响应度量是整条场景能否被验收的关键，缺了它场景就退化为愿望。因此场景既不是模板填空的产物，也不是需求的替代物，而是把质量诉求推到可判定状态的载体。
架构风格选择方法G · 架构设计高级架构风格可理解为对一类系统组织方式的命名与约定：风格固定了可用构件的种类、连接方式的种类，以及二者允许如何拼装。选型方法则以质量属性场景为判据，把候选风格的构件—连接件约束逐项映射为属性收益与代价，在具体子域上择优，而非寻找普适最优。其要点有三：其一，风格的本质是约束集合，符合约束才带来特定属性，而约束一旦采纳，包里每项战术的收益与副作用同时生效，且通常不只作用于一项质量属性；其二，同一风格在不同子域、不同负载形态与不同规模下，收益与代价可能整体反转，故不存在放之四海皆准的答案，只能就事论事地评估；其三，落锤前必须把代价显性化，说清放松哪条约束换取哪项属性。
架构文档化方法G · 架构设计进阶以「文档化相关视图，再文档化适用于多个视图的信息」为组织原则的架构文档化方法：先按预期用途与干系人关注选择视图，再表达每个视图的「如何组织、架构是什么、为何如此」，并以跨视图信息与一致性校验避免文档过载与失真。
效用树与敏感点权衡点分析G · 架构设计高级把质量属性自顶向下细化为带刺激与响应度量的场景并排序，形成效用树；再沿树把架构决策逐条映射到场景上，标出对单一属性响应影响显著者与同时反向影响多项者，并归纳风险主题。它把笼统的质量目标变成可探测、可排序、可聚焦的风险清单。效用树的结构可以逐层读出：根节点表示系统整体的好，其下一层列出该系统必须呈现的主要质量属性，再下一层把每个属性细化为与本系统相关的具体侧面，叶片位置放的是以刺激与响应度量写成的场景。它之所以被设计成树而非清单，是因为自顶向下逐层收窄能把笼统的属性名逼到可判定的场景，避免停留在可修改、高吞吐这类无法验收的层面。
代码复审与可读性治理H · 实现与构造进阶以评审流程把可读性与结构标准组织化、可教学地传播的治理方法：把代码评审从个人偏好检查转为有依据、有导师机制的常规活动，在变更合入前对结构、接口与可读性施加统一约束。
测试层次I · 测试基础测试层次是按开发生命周期阶段组织并一起管理的测试活动分组，通常从组件级逐层上升到系统级与验收级；每个层次针对不同的测试对象与关注点，回答不同的问题，并对应不同的缺陷类型与执行主体。
测试类型I · 测试基础测试类型是与特定质量特性相关的一组测试活动，如功能测试与非功能测试，也可按是否依赖内部结构分为黑盒、白盒与经验型；大多数测试类型可应用于每一个测试层次，层次与类型是两个正交的坐标。
测试金字塔与反模式I · 测试进阶测试金字塔是按粒度与数量组织自动化测试的模型：底层应有多得多的快速隔离单元测试，中层为适量服务/集成测试，顶层为少量端到端测试；倒置的金字塔（冰淇淋甜筒）与缺失中间层的沙漏是典型反模式。
测试替身与测试策略I · 测试进阶测试替身是在测试中替换生产对象的任何协作对象的泛称，包括哑元、伪造、桩、监视与模拟五类；按需要隔离的程度选择替身类型，并控制替身的使用范围，是平衡测试速度、确定性与保真度的关键策略。
质量门控与持续集成I · 测试进阶持续集成要求开发者频繁把改动合并回主线，并由自动化构建与测试验证；质量门控则用一组在分析时度量的条件判定制品是否可发布，任一条件不满足即阻断构建或合并，把测试与质量检查制度化为交付闸门。
软件测试过程模型I · 测试高级软件测试过程模型把测试描述为可治理、可管理、可实施的分层过程：组织级制定测试方针与策略，管理级规划、监控与收尾测试项目，动态级设计、实现、执行并报告具体测试，可配合不同开发生命周期使用。
可观测性信号关联方法K · 运维进阶用数值聚合、带上下文的事件记录与请求级路径追踪三类信号共同刻画系统，并通过统一的身份与时间基准把它们关联起来；价值在于信号可相互串联以定位根因，而非信号数量或支柱的划分。
技术债象限与偿还策略L · 演化与弃用进阶以「有意/无意」与「审慎/鲁莽」两组正交判据对债务分诊，据此制定差异化偿还策略：审慎有意者计划偿还，审慎无意者随认知更新修正，鲁莽者立即纠正，并按变更热点优先偿付利息最高的债务。
质量属性战术映射方法M · 横切·质量属性进阶战术是影响某项质量属性响应能否达成的设计决策，它直接作用于系统对某类刺激的反应。与模式的区别在于作用范围：战术瞄准单项质量属性的响应，模式描述的是特定语境下反复出现的设计问题及其被验证过的解法，用元素的角色、职责、关系与协作方式来表述。适用边界在于：一条设计决策如果说不清它针对哪类刺激、要改变哪项响应，就还不构成战术，只是普通的实现选择。把每项质量属性目标映射到一组可组合的战术，再由战术组合成架构策略、打包为模式，这一映射的作用是把抽象的质量目标转化为具体、可评审的设计动作。战术位于模式与单条质量属性之间：模式是面向完整问题的打包方案，粒度大、语境强；
可修改性战术应用M · 横切·质量属性进阶可修改性指系统在需求或环境变化时，以可接受的代价完成修改的能力。其方法以耦合、内聚与成本动因为依据应用一组战术：推迟绑定时间、局部化变更、防止涟漪效应，使修改集中在局部、缩小受影响模块数与回归风险，从而降低变更成本。判据不是代码是否整齐，而是「改动一个模块时，有多少其它模块必须随之改动」。影响范围由模块之间的相互牵连程度与模块内部职责的聚合程度共同决定：牵连越高、聚合越低，一次改动波及的范围就越广。变更成本等于改动本身的成本加上因耦合被牵连的其它模块的成本，故减少后者往往比减少前者更能显著降低总成本。
可用性战术应用M · 横切·质量属性进阶可用性讨论的起点是把两个词分清：失效指系统不再按规格交付服务，且这一情况能被参与者观察到；故障指可能导致失效的潜在原因。二者是因果而非同义关系，一组故障有可能引发失效，也可能被挡住而不引发。这个区分支撑了整章的策略：战术的作用就是阻止故障演化为失效，或者在无法阻止时把影响限定住，并让修复成为可能。由此也可以解释为什么没有宕机不能证明架构可用——故障可能一直在发生，只是尚未被观察到。围绕这个目标，可用性战术按目的分三类：检测故障、从故障中恢复、预防故障。
质量模型应用方法M · 横切·质量属性进阶以标准化的质量模型（由质量特性与子特性构成的框架）为共同参照，把分散的质量关切组织为可规定、可测量、可评价的维度，并据此在需求、设计与评价之间建立一致的映射。
质量属性权衡决策方法M · 横切·质量属性高级面对相互牵制的质量属性，先以场景明确各属性目标与可接受边界，再识别同时影响多个属性的权衡点，通过显式比较与优先级排序做出可解释、可复核、可撤销的决策。质量属性很少能同时最优：为提升性能引入缓存会加剧一致性难度，为增强安全增加校验会拖慢响应，为提高可用性增加冗余会抬高成本与复杂度，为改善可维护性增加抽象会消耗运行期资源。因此架构设计的本质不是让每个属性都最大化，而是在给定语境下选择一组彼此相容的目标，并对冲突处做出有依据的取舍。
平台团队与最薄可行平台N · 横切·团队与康威进阶以产品方式建设平台团队，把通用能力封装为可自助使用的内部产品，以降低流对齐团队的认知负荷、加速交付；并以最薄可行平台约束平台规模，避免臃肿平台制造新依赖。
DORA 交付效能指标N · 横切·团队与康威进阶以一组经过实证的软件交付效能指标——吞吐侧的变更前置时间、部署频率、失败部署恢复时间，与不稳定侧的变更失败率、部署返工率——衡量组织把变更交付到生产的效能，并用于改进而非考核。
准入与触发时机选择O · 方法论主干/跨域综合进阶决定何时、由谁把产物推进下一环节：人工门控可控但易漏、自动流转高效但可能放行半成品，应在「可信度门槛与发生频率」两个维度上选择人工、自动或半自动策略。
技术选型的够用原则O · 方法论主干/跨域综合进阶技术选型方法处理的是在标准、框架、架构风格与外部构件之间做选择的问题：按适用域与约束匹配需求，挑出刚好覆盖质量属性场景的方案，因为任何额外能力都伴随新的复杂度。其判据落在质量属性场景上——在能覆盖当前需求与可预见需求的前提下，选那个其余代价最小的方案，而不是功能清单最长或技术最新潮的那个。它要求同时说清三件事：当前方案满足哪些场景、刻意不满足哪些场景、以及在什么条件下应当改变选择，使选型从一次性拍板变成可持续复核的工程判断。据此，「够用」不是能力上的将就，而是把不产生收益的复杂度明确排除在外。
能力-成本-速度三角O · 方法论主干/跨域综合进阶在能力/质量、成本与交付速度之间取舍时，须区分一次性成本与持续成本，先量化各方案的人力、基础设施与运维开销；研究表明速度与稳定可兼得，成本优化的重点应是持续成本与减小变更批量。
质量属性冲突治理O · 方法论主干/跨域综合高级质量属性冲突治理，指在架构决策过程中把多个质量属性之间此消彼长的关系从隐性经验转为显式可裁决对象的成套做法。它处理的不是单个属性如何达成，而是当若干属性同时提出要求、且这些要求由同一批设计决策承载时，如何给出有依据、可追溯、可重议的取舍。这里的治理一词有两重含义：一是承认冲突的常态化，不把「所有属性同时最优」当作可追求的目标；二是把处理冲突的动作固定成流程，使结论不依赖某一次讨论中谁的声音更大。它的治理单位是场景而不是属性名词：属性只有被写成带刺激、环境与响应度量的场景之后，才可能被比较、被排序、被判为达成或未达成；离开场景，「性能好」「安全性高」这类表述无法支撑任何裁决。
粒度与边界设定O · 方法论主干/跨域综合高级决定模块、服务、知识域与团队按什么分解、切到多细：应围绕可能变化的设计决策（信息隐藏）而非处理步骤切分，用内聚耦合度量与认知负荷约束边界，并使架构边界与团队边界同步演化。
自动化方式选择O · 方法论主干/跨域综合进阶在规则/模板、模型生成与纯人工之间选择实现方式：模板与规则零成本且可控，模型与自动化适合高频或复杂场景；应按沉淀粒度与可信度门槛选择，并为自动化配置持续执行与反馈闭环。
复杂度阶梯与演进时机O · 方法论主干/跨域综合进阶在简单与复杂方案之间选择与进阶时机：复杂方案的建设、延迟与一致性成本更高，应先跑通最简单可工作的方案，待出现明确且当前的跨域或规模需求时再逐步演进，而非为预想的未来提前复杂化。
理解成本优先的简单原则O · 方法论主干/跨域综合进阶这里的简单性指采用人们熟悉且前后一致的模式与结构，使新加入的工程师也能较快理解系统，而不是指功能数量少。书中把简单性列为可维护性的三根支柱之一，与可运维性、可演化性并列，理由很直接：维护成本占据软件生命周期支出的大头，而复杂度会让每一个改动系统的人都变慢，进而推高维护成本。判别困难也写得很诚实——是否简单带有主观成分，缺少客观刻度，因此同一个系统可以因为把复杂实现藏在简单接口之后而被认为简单，也可以因为实现本身直白却暴露大量内部细节而被认为复杂。所以简单性应作为设计目标显式提出，并接受它需要靠判断而非靠计数来裁定，也需要在评审中被反复追问，而不是默认它已经成立。
增量演化与一致性治理O · 方法论主干/跨域综合高级在演化中治理一致性：优先用增量同步、契约与弃用信号替代全量重建，用适应度函数持续防止架构漂移，并以 expand/contract、绞杀者等模式渐进迁移，使变更小批量、可回退。
度量与反馈闭环O · 方法论主干/跨域综合高级建立轻量、客观、可复现的评估体系与反馈闭环：用真实场景与基线度量、以多指标协同避免单点失真，并把度量接入持续执行与复测；同时警惕古德哈特定律，防止指标一旦成为目标即被博弈。
§3技术实践 technology（32）
需求可追溯性与影响分析F · 概念与需求进阶以需求库为中枢，把需求条目、属性与上下游制品（干系人需求、系统需求、设计、测试、代码）建立可查询的追踪关系，并以结构化查询支持变更影响分析的需求管理平台化落地。
AWS 良好架构框架G · 架构设计进阶AWS 发布的云架构最佳实践对照框架，以运营卓越、安全、可靠性、性能效率、成本优化、可持续性六大支柱组织设计原则与评审问题，用于一致地度量工作负载与最佳实践的偏差。
GCP 良好架构框架G · 架构设计进阶Google Cloud 发布的云架构建议框架，以运营卓越、安全隐私与合规、可靠性、成本优化、性能优化、可持续性六大支柱及 AI/ML、金融等跨支柱视角，指导设计安全、高效、韧性、高性能且可持续的云拓扑。
Azure 架构中心G · 架构设计基础Microsoft 维护的 Azure 架构中心，汇集云架构风格目录（N 层、微服务、事件驱动等，含适用性、收益与挑战）与安全部署实践，指导按业务驱动与非功能需求选择风格并安全发布变更。
ThoughtWorks 技术雷达G · 架构设计进阶Thoughtworks 技术咨询委员会每年发布两次的技术快照，以技术/方法条目（blip）经四象限与四环（Adopt/Trial/Assess/Caution）组织，表达对技术采用程度的带观点推荐，并明确不追求全面、不接受厂商付费影响。
SonarQube 静态分析平台H · 实现与构造进阶SonarQube Server 是面向持续集成的静态代码分析平台，以规则引擎自动检测代码坏味道、缺陷与安全热点，并通过质量门控把分析度量转化为变更准入判断，同时区分整体代码与新代码以支撑增量治理。
SQALE 技术债评估方法H · 实现与构造高级SQALE 是一套以生命周期期望为基准、力求客观可复现地评估源代码质量并量化技术债的方法，由若干基本原则与质量模型、分析模型、指数、指标等组件构成，供组织与厂商实现。
技术债量化度量指标H · 实现与构造高级技术债量化度量把代码缺陷折算为可计算的债务规模与比率：以修复成本累加得到技术债额，用技术债比率（债务与开发成本之比）映射可维护性评级，并区分整体代码与新代码以支撑增量治理。
依赖结构度量与渐进收紧治理H · 实现与构造高级依赖结构度量与渐进收紧治理把组件间的依赖关系折算为稳定性与抽象度等可计算指标，用归一化距主序列距离定位偏离健康线的组件，并以先告警、后报错的级联阈值在受控节奏内把结构拉回健康区间。
持续集成服务与流水线I · 测试进阶持续集成服务与流水线是把「频繁合并回主线、每次合并自动构建并运行测试」制度化的技术载体：由单一代码主线、自动化构建与测试执行、结果回传与即时反馈构成，使集成错误在产生后最短窗口内暴露。
关键字驱动测试框架I · 测试高级关键字驱动测试（KDT）是 ISO/IEC/IEEE 29119-5 定义的一种自动化测试框架范式：把测试操作抽象为可复用的关键字，测试用例由「关键字＋参数」序列描述，驱动层负责解释执行，从而将测试意图与底层脚本实现分离。
xUnit 测试框架族I · 测试进阶xUnit 测试框架族是按「测试类—测试方法—断言—夹具」结构组织并自动执行单元测试的一类框架，命名源自 JUnit 及其衍生家族；它把测试书写、发现、执行与报告统一为开发者可直接使用的代码骨架，是单元测试与测试驱动开发的主要工具载体。
Kubernetes 部署编排J · 部署进阶Kubernetes 是容器编排平台，其 Deployment 控制器以声明式方式管理无状态工作负载的创建、扩缩与更新，默认采用滚动更新策略，并通过保留历史 ReplicaSet 支持版本回退。
服务等级目标与错误预算K · 运维高级用 SLI（好事件/总事件）度量服务水平，设定小于 100% 的 SLO 目标，并以错误预算等于 100% 减 SLO 驱动发布与加固决策；SLA 则是含后果的对外契约。
无指责复盘实践K · 运维进阶无指责复盘是一种事故发生后的书面复盘，其记录对象包括影响范围、处置与缓解过程、根因分析与后续行动项，而它的定义性特征在于聚焦方向：考察导致事件的那些系统性原因与当时的决策情境，而不是追查哪个个人或团队该被追究。它之所以被称为一种文化而不只是一份文档，是因为它同时规定了两件事——产出什么内容，以及以什么态度对待参与者。书中把它归入提升系统抵御人为失误能力的手段之列，与测试、回滚机制、渐进发布、监控与可观测性、界面设计并列，说明它的定位是组织层面的可靠性工程实践，而非单纯的行政流程。理解这一定义要抓住三组区分。
可修改性战术实现M · 横切·质量属性进阶可修改性战术的实现，指把推迟绑定时间、局部化变更与防止涟漪效应这三类设计决策落到具体结构机制上，包括接口与间接层、易变决策的封装位置、依赖方向约束与依赖反转，目标是缩小每一次修改的影响半径。第八章节把这些手段归入三个抽屉。一是提升内聚，做法是拆分职责过杂的模块、把散落各处的同类职责重新归拢。二是降低耦合，做法是加壳封装、插入居间者、把公共能力抽成共享服务、约束模块可见与可依赖的范围。三是推迟绑定，做法涵盖构件替换、编译期参数化、切面、配置期赋值、资源文件、运行期发现、参数解释、共享仓库与多态分派。
交付效能度量与仪表化N · 横切·团队与康威进阶把交付效能指标的采集、聚合与呈现平台化：从版本控制与流水线事件自动计算并持续反馈，并以治理机制约束指标被博弈（gaming）的风险，使度量服务于改进而非考核。
§4层间依赖边
| 来源（外→内） | 类型 | 目标 | 说明 |
|---|---|---|---|
| 需求工程过程 | 依据推导 | 软件需求 | 需求工程过程以软件需求为工程对象 |
| 需求获取 | 依据推导 | 干系人与需要 | 需求获取以干系人需要为源头 |
| 干系人识别与分析 | 依据推导 | 干系人与需要 | 干系人识别与分析以干系人概念为依据 |
| 需求规格说明 | 依据推导 | 需求可追溯性与可验证性 | 规格说明落实可验证与可追溯特性 |
| 需求属性与优先级 | 依据推导 | 业务与任务价值 | 优先级排序服务于业务与任务价值最大化 |
| 测试层次 | 依据推导 | 测试作为验证与反馈机制本质 | 测试层次以测试的验证与反馈本质为依据 |
| 测试类型 | 依据推导 | 可测试性本质 | 测试类型设计以可测试性为结构前提 |
| 测试驱动开发 | 依据推导 | 测试作为验证与反馈机制本质 | TDD 以测试作为快速反馈机制为依据 |
| 测试金字塔与反模式 | 依据推导 | 测试作为验证与反馈机制本质 | 测试金字塔依据测试的验证与成本本质 |
| 质量门控与持续集成 | 依据推导 | 测试作为验证与反馈机制本质 | 质量门控以测试作为验证反馈机制为依据 |
| 部署流水线 | 依据推导 | 构建发布运行分离 | 部署流水线依据构建发布运行分离 |
| 封闭构建 | 依据推导 | 构建发布运行分离 | 封闭构建依据构建阶段的可复现要求 |
| 配置外置与显式化 | 依据推导 | 开发生产一致性 | 配置外置服务于开发生产一致性 |
| 渐进暴露部署策略 | 依据推导 | 部署即变更管理 | 渐进暴露依据部署即变更管理 |
| 可回滚性与爆炸半径控制 | 依据推导 | 部署即变更管理 | 可回滚与爆炸半径控制依据变更管理 |
| 服务等级目标方法 | 依据推导 | 可靠性即风险管理 | SLO 方法源于可靠性即风险管理 |
| 可观测性信号关联方法 | 依据推导 | 可观测性本质 | 信号关联与追踪依据可观测性本质 |
| 事件响应与无指责复盘方法 | 依据推导 | 故障不可避免性与容错 | 事件响应与复盘依据故障不可避免性 |
| 混沌工程方法 | 依据推导 | 故障不可避免性与容错 | 混沌工程依据故障不可避免性 |
| 容量规划与变更管理方法 | 依据推导 | 度量驱动的反馈闭环 | 容量与变更管理依据度量驱动的反馈闭环 |
| 服务等级目标方法 | 依据推导 | 架构即权衡 | SLO 目标选择体现架构即权衡 |
| 行为保持重构 | 依据推导 | 技术债本质 | 行为保持重构是偿还技术债的核心手段 |
| 代码坏味道启发式 | 依据推导 | 变更成本随复杂度增长 | 坏味道是变更成本上升的可观察信号 |
| 技术债象限与偿还策略 | 依据推导 | 技术债本质 | 债务象限与偿还策略依据技术债本质 |
| 演进式架构 | 依据推导 | 演化的不可逆性 | 演进式架构以演化不可逆为前提 |
| 架构适应度函数 | 依据推导 | 架构侵蚀与漂移 | 适应度函数用于抑制架构侵蚀与漂移 |
| 遗留系统渐进治理 | 依据推导 | 变更成本随复杂度增长 | 遗留治理以降低变更成本为目标 |
| 弃用与日落策略 | 依据推导 | 演化的不可逆性 | 弃用策略是演化不可逆下的有序退场 |
| 演进式架构 | 依据推导 | 软件演化定律 | 演进式架构承接软件必须持续演化的定律 |
| 质量属性战术映射方法 | 依据推导 | 质量属性不可直接测量 | 战术映射依据质量属性须可操作化 |
| 可修改性战术应用 | 依据推导 | 可维护性本质 | 可修改性战术服务于可维护性本质 |
| 可用性战术应用 | 依据推导 | 可靠性与可用性 | 可用性战术服务于可靠性与可用性 |
| 可维护性评估方法 | 依据推导 | 可维护性本质 | 可维护性评估以可维护性本质为判据 |
| 质量属性权衡决策方法 | 依据推导 | 架构即权衡 | 权衡决策方法依据架构即权衡的本质 |
| 逆向康威操作 | 依据推导 | 组织-架构同态 | 逆向康威操作依据组织-架构同态关系 |
| 团队拓扑四类型 | 依据推导 | 认知负荷约束 | 团队拓扑四类型依据认知负荷约束 |
| 团队交互模式 | 依据推导 | 团队边界与架构边界耦合 | 交互模式设计依据团队边界耦合 |
| 平台团队与最薄可行平台 | 依据推导 | 认知负荷约束 | 平台团队以降低认知负荷为目的 |
| DORA 交付效能指标 | 依据推导 | 组织即设计系统 | 交付效能指标度量组织作为设计系统的产出 |
| 团队边界治理 | 依据推导 | 团队边界与架构边界耦合 | 团队边界治理依据边界耦合关系 |
| 覆盖与精度的不对称权衡 | 依据推导 | 本质复杂度与偶然复杂度 | 覆盖与精度只能在本质复杂度不可消除的空间中选点 |
| 覆盖与精度的不对称权衡 | 依据推导 | 权衡的不可消除性 | 代价不对称的取舍依据权衡不可消除 |
| 准入与触发时机选择 | 依据推导 | 权衡的不可消除性 | 准入时机的质量门槛与便利性是权衡的体现 |
| 技术选型的够用原则 | 依据推导 | 架构即权衡 | 风格选型本质是以约束换取期望属性 |
| 能力-成本-速度三角 | 依据推导 | 权衡的不可消除性 | 能力成本速度三角是权衡不可消除的实例 |
| 质量属性冲突治理 | 依据推导 | 架构即权衡 | 属性冲突治理依据架构即权衡的本质 |
| 质量属性冲突治理 | 依据推导 | 权衡的不可消除性 | 属性冲突只能显式化与排序，无法消除 |
| 粒度与边界设定 | 依据推导 | 本质复杂度与偶然复杂度 | 粒度决定偶然复杂度与理解成本 |
| 自动化方式选择 | 依据推导 | 权衡的不可消除性 | 自动化方式按可信度与频率取舍 |
| 复杂度阶梯与演进时机 | 依据推导 | 本质复杂度与偶然复杂度 | 复杂度阶梯以降低认知复杂度为目标 |
| 理解成本优先的简单原则 | 依据推导 | 本质复杂度与偶然复杂度 | 理解成本即认知复杂度的核心度量 |
| 增量演化与一致性治理 | 依据推导 | 权衡的不可消除性 | 演化中的一致性取舍依据权衡不可消除 |
| 度量与反馈闭环 | 依据推导 | 权衡的不可消除性 | 度量与反馈是对取舍效果的检验 |
| 度量与反馈闭环 | 依据推导 | 质量属性不可直接测量 | 度量方法依据质量属性不可直接测量 |
| 架构文档化方法 | 依据推导 | 架构描述与对应关系 | 文档化方法以架构描述为对象组织视图与对应关系 |
| 架构文档化方法 | 依据推导 | 视图与视角 | 文档化依视图与视角约定组织架构信息 |
| 效用树与敏感点权衡点分析 | 依据推导 | 质量属性不可直接测量 | 效用树把不可直接测量的质量属性操作化为场景 |
| 效用树与敏感点权衡点分析 | 依据推导 | 架构即权衡 | 敏感点与权衡点分析是架构权衡判断的内核 |
| 战略式编程与持续设计投入 | 依据推导 | 可读性与认知负荷 | 持续设计投入以降低长期认知负荷为目标 |
| 战略式编程与持续设计投入 | 依据推导 | SOLID 职责划分与替换性 | 战略式设计以职责划分与替换性为判据 |
| 代码复审与可读性治理 | 依据推导 | 可读性与认知负荷 | 可读性治理以可读性为工程属性为前提 |
| 代码复审与可读性治理 | 依据推导 | 内聚与耦合 | 评审以高内聚低耦合作为结构判据 |
| 需求可追溯性与影响分析 | 实现 | 需求规格说明 | 追溯与影响分析落地需求规格说明 |
| 需求可追溯性与影响分析 | 实现 | 需求属性与优先级 | 需求属性与追踪关系在平台中落地 |
| 需求技术债识别与度量 | 实现 | 需求规格说明 | 以规格质量特性识别需求技术债 |
| 需求技术债识别与度量 | 实现 | 需求工程过程 | 需求债识别与度量嵌入需求工程过程 |
| 交付效能度量与仪表化 | 实现 | DORA 交付效能指标 | 交付指标的自动采集与仪表化落地 |
| 交付效能度量与仪表化 | 实现 | 度量与反馈闭环 | 交付度量平台实现持续反馈闭环 |
| 团队拓扑落地与规模化 | 实现 | 团队拓扑四类型 | 规模化组织中落地团队拓扑四类型 |
| 团队拓扑落地与规模化 | 实现 | 平台团队与最薄可行平台 | 以最薄可行平台落地平台团队 |
| 团队拓扑落地与规模化 | 实现 | 团队边界治理 | 以流动信号持续校准团队边界 |
| AWS 良好架构框架 | 实现 | 质量属性场景与ATAM | AWS 支柱评审落地质量属性场景分析 |
| GCP 良好架构框架 | 实现 | 质量属性场景与ATAM | GCP 支柱原则承载质量属性场景分析 |
| Azure 架构中心 | 实现 | 架构风格选择方法 | Azure 风格目录指导架构风格选择 |
| Azure 架构中心 | 实现 | 渐进暴露部署策略 | Azure 安全部署落地渐进暴露策略 |
| ThoughtWorks 技术雷达 | 实现 | 技术选型的够用原则 | 技术雷达采用环支撑技术选型够用原则 |
| AWS 良好架构框架 | 实现 | 效用树与敏感点权衡点分析 | AWS 支柱冲突识别支撑效用树权衡点 |
| SonarQube 静态分析平台 | 实现 | 代码复审与可读性治理 | 静态分析平台为代码评审提供自动化检查信号 |
| SonarQube 静态分析平台 | 实现 | 度量与反馈闭环 | 平台产出可度量指标并驱动反馈闭环 |
| SonarQube 静态分析平台 | 实现 | 质量门控与持续集成 | 质量门控把分析结果转化为变更准入判断 |
| SonarQube 静态分析平台 | 实现 | 代码坏味道启发式 | 规则引擎自动化识别代码坏味道 |
| SQALE 技术债评估方法 | 实现 | 可维护性评估方法 | SQALE 为可维护性提供量化评估方法 |
| SQALE 技术债评估方法 | 实现 | 技术债象限与偿还策略 | SQALE 为技术债量化与偿还提供方法基础 |
| SQALE 技术债评估方法 | 实现 | 质量模型应用方法 | SQALE 是面向源码质量的具体质量模型实例 |
| 技术债量化度量指标 | 实现 | 可维护性评估方法 | 债务比率与评级把可维护性折算为可计算指标 |
| 技术债量化度量指标 | 实现 | 技术债象限与偿还策略 | 债务量化支撑按偿还优先级治理技术债 |
| 技术债量化度量指标 | 实现 | 度量与反馈闭环 | 债务度量指标纳入度量与反馈闭环 |
| 依赖结构度量与渐进收紧治理 | 实现 | 架构适应度函数 | 依赖结构度量与阈值收紧是架构适应度函数的代码层落地 |
| 持续集成服务与流水线 | 实现 | 质量门控与持续集成 | 持续集成服务落地质量门控与持续集成方法 |
| 关键字驱动测试框架 | 实现 | 软件测试过程模型 | 29119-5 关键字驱动测试实现分层测试过程模型 |
| xUnit 测试框架族 | 实现 | 测试层次 | xUnit 框架族支撑组件级单元测试层次 |
| xUnit 测试框架族 | 实现 | 测试金字塔与反模式 | xUnit 单元测试构成测试金字塔底层 |
| 关键字驱动测试框架 | 实现 | 测试类型 | 关键字驱动测试作为规格化黑盒测试类型的实现 |
| Kubernetes 部署编排 | 实现 | 渐进暴露部署策略 | K8s 滚动更新实现渐进暴露 |
| Kubernetes 部署编排 | 实现 | 可回滚性与爆炸半径控制 | 历史 ReplicaSet 支撑版本回退 |
| 不可变基础设施实现 | 实现 | 封闭构建 | 镜像构建一次并不可变复用 |
| 不可变基础设施实现 | 实现 | 发布与部署解耦 | 以实例替换替代就地修改 |
| 蓝绿部署 | 实现 | 渐进暴露部署策略 | 双环境整体切换的渐进暴露 |
| 蓝绿部署 | 实现 | 可回滚性与爆炸半径控制 | 切回旧环境实现即时回滚 |
| 金丝雀发布 | 实现 | 渐进暴露部署策略 | 按健康指标逐步扩大流量暴露 |
| 金丝雀发布 | 实现 | 可回滚性与爆炸半径控制 | reroute 回退控制爆炸半径 |
| 部署自动化 | 实现 | 部署流水线 | 部署步骤脚本化与自动执行 |
| 部署自动化 | 实现 | 发布工程 | 可复现部署支撑发布工程 |
| 部署流水线工具化 | 实现 | 部署流水线 | 多阶段制品晋级即部署流水线 |
| 部署流水线工具化 | 实现 | 发布与部署解耦 | 构建一次逐环境晋级解耦发布部署 |
| 断路器与重试退避 | 实现 | 可用性战术应用 | 断路器与重试实现可用性战术 |
| 断路器与重试退避 | 实现 | 质量属性战术映射方法 | 容错战术映射至质量属性 |
| 可观测性信号采集 | 实现 | 可观测性信号关联方法 | 可观测信号关联方法的技术实现 |
| 可观测性信号采集 | 实现 | 四大黄金信号监控方法 | 四大黄金信号的采集与呈现 |
| 服务等级目标与错误预算 | 实现 | 服务等级目标方法 | 服务等级目标的度量与设定 |
| 服务等级目标与错误预算 | 实现 | 错误预算政策与燃尽率告警 | 错误预算与燃尽率告警实现 |
| 混沌工程实践 | 实现 | 混沌工程方法 | 混沌工程方法的实验化落地 |
| 无指责复盘实践 | 实现 | 事件响应与无指责复盘方法 | 无指责复盘的文档化落地 |
| DORA 交付指标 | 实现 | DORA 交付效能指标 | DORA 交付效能指标的度量实现 |
| 架构适应度函数工具化 | 实现 | 架构适应度函数 | 适应度函数工具化实现架构适应度函数方法论 |
| 架构适应度函数工具化 | 实现 | 演进式架构 | 工具化持续校验支撑演进式架构的增量变更原则 |
| 绞杀者渐进式替换 | 实现 | 遗留系统渐进治理 | 绞杀者渐进替换实现遗留系统渐进治理方法论 |
| 绞杀者渐进式替换 | 实现 | 演进式架构 | 绞杀者增量迁移体现有引导的增量演进 |
| 质量模型工具化 | 实现 | 质量模型应用方法 | SQuaRE 质量模型工具化实现质量模型应用方法 |
| 质量模型工具化 | 实现 | 可维护性评估方法 | 质量模型为可维护性评估提供子特性维度 |
| 可维护性量化 | 实现 | 可维护性评估方法 | SQALE 量化技术债与可维护性实现可维护性评估方法 |
| 可修改性战术实现 | 实现 | 质量属性战术映射方法 | 可修改性战术实现质量属性战术映射方法 |
| 架构决策记录 | 依据推导 | 架构即权衡 | 决策记录依架构即权衡，留存取舍与理由 |
| 质量属性场景与ATAM | 依据推导 | 架构即权衡 | ATAM 以架构权衡为根本前提 |
| 架构风格选择方法 | 依据推导 | 架构即权衡 | 风格选择依质量属性权衡而非对错 |
| 领域驱动战略设计 | 依据推导 | 边界与接口隔离 | 限界上下文依边界与接口隔离原理 |
| 领域驱动战略设计 | 依据推导 | 康威定律 | DDD 边界与组织结构相互塑造（康威） |
| 重构手法族 | 依据推导 | 内聚与耦合 | 重构以改善内聚耦合、降低变更成本 |
| 信息隐藏模块化分解 | 依据推导 | 信息隐藏 | 信息隐藏模块分解是信息隐藏原理的方法化 |