软件工程 / 架构设计方法论知识图谱 / 分组目录 / 本质层 / 架构描述与对应关系
essence · G · P1 · active

架构描述与对应关系

Architecture Description and Correspondences
P1进阶verified本质 essence方法原则G · 架构设计GL-ESSENCE · 本质层

§1摘要与结论

TL;DR · 一句话结论

架构本身是不可见的抽象，表达架构的工件称为架构描述（AD）。AD 由描述元素、模型种类与对应关系构成，并以对应的强制规则约束视图内部及视图之间的一致性、可追溯与组合，使多份面向不同关注点的局部表达汇成对同一架构的统一、可校验的整体。

别名：architecture description、AD、correspondence、对应关系、模型种类、架构理由　|　英文：Architecture Description and Correspondences　|　类型：方法原则 / concept

§2局部关系图

架构描述与对应关系 的 1-2 跳邻域关系图前置依赖（prerequisite）：关注点分离是信息隐藏的前提前置依赖（prerequisite）：理解信息隐藏是评估内聚耦合的前提前置依赖（prerequisite）：内聚耦合度量指导边界划分前置依赖（prerequisite）：先划定边界，才能约束依赖方向前置依赖（prerequisite）：关注点分离促成知识的单一归属组合（combination）：信息隐藏与关注点分离常组合使用前置依赖（prerequisite）：边界划分是对多重质量属性的权衡组合（combination）：单一知识源与高内聚同向协同依据推导（derives_from）：文档化方法以架构描述为对象组织视图与对应关系依据推导（derives_from）：文档化依视图与视角约定组织架构信息组合（combination）：决策记录与文档化方法共同承载架构决策与理由促成（enables）：架构文档是架构评估流程的输入前置依赖（prerequisite）：视图与视角概念是理解架构描述构成与对应关系的前提组合（combination）：架构描述记录边界与接口的外部可见属性组合（combination）：架构描述按干系人关注点组织局部表达案例印证（case_instance）：印证：按关注点将系统分解为可独立处理的 18 个模块案例印证（case_instance）：印证：以视图与依赖图文档化架构，支撑无源码理解案例印证（case_instance）：印证：去中心化与本地优先等主张皆为显式架构取舍案例印证（case_instance）：印证：以适配器与事件驱动组合出可扩展的架构风格案例印证（case_instance）：印证：以双通道与密钥隔离划清信任与能力边界案例印证（case_instance）：印证：以内聚与耦合维度逐点评估通道结构案例印证（case_instance）：印证：特化标识由提供者构造期绑定，通用契约零扩展案例印证（case_instance）：张力：服务定位的隐式依赖与静默短路削弱依赖倒置案例印证（case_instance）：印证：双半边架构以同源接口维持清晰边界案例印证（case_instance）：违背：依赖声明不实（声明一项却消费多项）削弱依赖倒置案例印证（case_instance）：印证：以分层文档组织视图，再补跨视图信息案例印证（case_instance）：印证：按不同关注点组织层级与模块视图案例印证（case_instance）：印证：把不可见的架构转写为可复核的架构描述案例印证（case_instance）：印证：以装配与注入关系还原依赖方向案例印证（case_instance）：印证：以蓝本为参照的多视图文档与深链互引案例印证（case_instance）：印证：查询引擎、工具、权限、记忆的关注点分离案例印证（case_instance）：印证：多源交叉验证与分章文档化案例印证（case_instance）：印证：五段式节点页与图谱化文档案例印证（case_instance）：印证：事件地图交叉核对声明点与派发点核验埋点前置依赖（prerequisite）：模块化目标是信息隐藏判据的前提前置依赖（prerequisite）：模块划分质量以内聚耦合衡量前置依赖（prerequisite）：关注点分离是理解与选择架构风格的认知基础组合（combination）：风格选择是架构权衡的典型对象前置依赖（prerequisite）：关注点分离是视图与视角划分的基础组合（combination）：视图记录边界与接口的外部可见属性组合（combination）：模块化是关注点分离在结构上的体现依据推导（derives_from）：决策记录依架构即权衡，留存取舍与理由依据推导（derives_from）：ATAM 以架构权衡为根本前提依据推导（derives_from）：限界上下文依边界与接口隔离原理前置依赖（prerequisite）：识别敏感点与权衡点是记录架构决策的前提架构描述与对应关系架构描述与对应关系（ESS-G-07）harness 源码架构…harness 源码架构解析（CAS-X-09）关注点分离关注点分离（ESS-G-01）边界与接口隔离边界与接口隔离（ESS-G-03）视图与视角视图与视角（ESS-G-06）架构文档化方法架构文档化方法（MTH-G-05）架构即权衡架构即权衡（ESS-O-02）内聚与耦合内聚与耦合（ESS-H-02）信息隐藏信息隐藏（ESS-H-01）质量属性场景与ATAM质量属性场景与ATAM（MTH-G-02）可观测性信号采集可观测性信号采集（TEC-K-02）preset 通道耦合分…preset 通道耦合分析（CAS-X-05）Open Code Re…Open Code Review 图谱（CAS-X-15）依赖倒置与依赖规则依赖倒置与依赖规则（ESS-G-02）模块化与分解模块化与分解（ESS-G-04）去中心化聊天架构逆向去中心化聊天架构逆向（CAS-X-01）网申填写扩展逆向架构网申填写扩展逆向架构（CAS-X-02）架构风格架构风格（ESS-G-05）DRY 单一知识来源DRY 单一知识来源（ESS-H-03）架构决策记录架构决策记录（MTH-G-01）领域驱动战略设计领域驱动战略设计（MTH-G-04）dsh-manager …dsh-manager 插件深度分析（CAS-X-08）dsh 插件依赖增量定位dsh 插件依赖增量定位（CAS-X-10）Claude Code …Claude Code 架构逆向（CAS-X-13）
前置依赖实现依据推导案例印证对比冲突
以本节点为中心，静态内联 1–2 跳邻域：内环 5 个直接邻接、外环 18 个二跳节点，共 24 个节点；连线按边类型着色（六类配色见下）。构建期计算，无运行期脚本。

§3原理 · 为什么

架构是抽象而非工件：系统真实的元素、关系与设计演化原则无法被直接读取，团队所依据、评审与传承的其实是表达架构的工件，即架构描述（AD）。若把二者混同，就会把某一份文档误当作架构本身，既难以发现被遗漏的部分，也无法判断文档是否已与系统脱节。AD 之所以要被结构化为描述元素与对应关系，是因为单一表达无法同时回应所有干系人的关注点：不同读者关心不同侧面，必须允许多份局部表达并存。但局部表达并存又会带来新的风险——同一元素在不同表达中含义不同、相互引用断裂，读者被迫自行调和矛盾。对应关系及其规则正是为此而设：它把视图之间的组合、细化、一致性、可追溯、依赖与约束等联系显式声明并强制，使多份视图不至于各自漂移。此外，AD 还承载架构决策与理由，让「为何如此、放弃了什么」随描述一起被继承，而不是只留下既成结论。因此 AD 的价值不在篇幅，而在于它能否被独立校验、被追溯，并在系统演进后仍与实现保持一致；缺乏这种一致性的描述，无论多精美，都会迅速退化为误导。

§4机制 · 如何运作

架构描述由一组描述元素构成：干系人、关注点、视角、视图、模型种类，以及由视角或模型种类引入的构件；任何进入描述的条目都是描述元素。模型种类定义一类模型的构造约定，视图由若干按该约定构造的模型组成，因而同一视角下可以并存多个模型。对应关系表达描述元素之间的关系，对应规则则强制这些关系成立，常见类别包括组合、细化、一致性、可追溯、依赖、约束与义务，既可作用于单个描述内部，也可跨描述发挥作用。架构决策影响描述元素并关联一个或多个关注点，做决策又可能引出新的关注点；架构理由记录决策依据、推理与被否决的备选方案。这样一来，谁关心什么、用什么表达、表达之间如何保持一致，都被结构化为可查、可校验的元素与关系，而不是散落在图与段落之间、靠读者自行调和矛盾。

§5工程 · 怎么落地

实践中应先把描述元素类型固定下来：明确哪些条目属于描述元素、采用哪些模型种类、需要哪几类对应关系，再据此组织内容，而不是先画图后补关系。对应规则要按需选择，只对真正需要保持一致或可追溯的关系施加约束，避免把全部视图两两相连而制造维护负担；对应可跨越单个描述，使多份描述之间也能声明继承或一致性关系。为控制规模，可把对应关系与规则纳入自动化一致性校验，在变更后重新验证跨视图引用是否仍然成立。描述元素与系统实现之间应保持可追踪：需求、关注点、描述元素、决策与下游制品之间建立链接，使文档不至于在系统演进后悄然过期。对无法自动校验的关系，应说明其维护责任与复核时点，而不是假定一次建立即可长期有效；关键描述元素还应指派责任人，使一致性维护有人承担，而非默认由读者兜底。

§6权衡卡

代价 · 风险

显式对应关系带来可校验与可追溯，也带来维护成本：关系越多、规则越严，变更后需要同步更新的链接就越多，一旦与实现脱节，完整的对应网络反而会提供虚假的一致性信心。

另一类失效是把描述等同于架构，投入大量精力打磨文档的形式完整，却忽略了它是否仍然描述真实系统；过度追求形式还会诱使团队为满足规则而建立无实质意义的对应，使描述沦为填表。

还有一类风险是描述僵化：为维持稳定而拒绝更新，使 AD 逐渐偏离实际架构，后来者据此做出的判断因此建立在过时前提之上。

因此对应关系的粒度与严格度应与系统关键性、变更频率和合规压力相称：高风险、强监管的系统值得更密的追溯，快速探索阶段则可只保留关键链路。

原文要点
  • 判断标准始终是这些关系是否在变更与验收时真的被使用，而不是数量多少；宁可保留少量可靠链接，也不要堆积无人维护的形式链接。

权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。

§7学习路径条

ESS-G-06视图与视角→ESS-G-07架构描述与对应关系

§8案例带

CAS-X-09 · 经 direct

harness 源码架构解析

对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。

CAS-X-01 · 经 ESS-G-01

去中心化聊天架构逆向

对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。

CAS-X-02 · 2 跳派生：当前节点 → ESS-G-01 → ESS-G-05

网申填写扩展逆向架构

对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。

CAS-X-03 · 2 跳派生：当前节点 → ESS-G-01 → ESS-H-03

网申 v3 多模块解耦

一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。

CAS-X-04 · 2 跳派生：当前节点 → ESS-G-01 → ESS-H-03

网申 v2 深度重构

一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。

CAS-X-05 · 2 跳派生：当前节点 → ESS-G-03 → ESS-H-02

preset 通道耦合分析

对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。

CAS-X-08 · 经 ESS-G-03

dsh-manager 插件深度分析

以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。

CAS-X-10 · 2 跳派生：当前节点 → ESS-G-03 → ESS-G-02

dsh 插件依赖增量定位

以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。

CAS-X-11 · 2 跳派生：当前节点 → ESS-G-01 → ESS-G-04

Hermes 七层架构总览

对八千余文件的工业级 AI Agent 项目做七层架构总览逆向，揭示其「越用越聪明」的自进化闭环如何在层间传导的控制型架构案例。

CAS-X-12 · 2 跳派生：当前节点 → ESS-G-03 → ESS-O-02

MCP 四件套选型对比

对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。

CAS-X-13 · 经 ESS-G-01

Claude Code 架构逆向

以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。

CAS-X-15 · 经 MTH-G-05

Open Code Review 图谱

对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。

§9信源与核验

核验状态True（verified）
置信度high
复核日期2026-10-12
生命周期active
规范信源STD-001、BK-013、OFF-015、OFF-016、STD-013
书证核验BK-007 Ch21.1（partial）；BK-013 Ch3.5 Relation to Other Kinds of Views（direct），Ch5.1 Overview（direct），ChSection 4. Mapping Between Views（direct）
入口链接http://www.iso-architecture.org/ieee-1471/cm/　https://www.iso.org/standard/74393.html
勘误
常见误解：架构就是架构文档，二者是同一事物
核验结论：架构是抽象（概念或感知），架构描述（AD）是表达该架构的工件；二者不可混同，描述可能遗漏或滞后于真实架构　[STD-001]
勘误
常见误解：对应关系只是视图之间的示意连线，没有约束力
核验结论：对应关系表达描述元素间关系，对应规则强制其成立（组合/细化/一致性/可追溯/依赖/约束/义务），支持跨视图一致性与可追溯　[STD-001]

§10原始关系清单

展开：本节点的全部原始关系边（5 条，含边 ID 与方向）
关系方向对端节点说明
案例印证← CAS-X-09harness 源码架构解析
E-964		印证：把不可见的架构转写为可复核的架构描述
组合← ESS-G-01关注点分离
E-730		架构描述按干系人关注点组织局部表达
组合→ ESS-G-03边界与接口隔离
E-729		架构描述记录边界与接口的外部可见属性
依据推导← MTH-G-05架构文档化方法
E-721		文档化方法以架构描述为对象组织视图与对应关系
前置依赖← ESS-G-06视图与视角
E-728		视图与视角概念是理解架构描述构成与对应关系的前提