软件工程 / 架构设计方法论知识图谱 / 分组目录 / 横切·团队与康威
横切组 · N · 29 节点

横切·团队与康威

GCC-N
横切组基础进阶高级29 节点

§1组简介

组目录:本质层方法论层技术实践层域·概念与需求域·架构设计域·实现与构造域·测试域·部署域·运维域·演化与弃用域·质量属性域·团队与康威域·方法论主干域·跨域横切·质量属性横切·技术债横切·团队与康威案例层

本组 29 个节点，类型为 横切组，域 N，覆盖阶段 基础 / 进阶 / 高级。

← 上一页组总索引全局交互总览视图视图入口

§2成员节点目录

节点 ID名称层/来源阶段简介
ESS-N-01康威定律本质 essence进阶设计系统的组织受沟通结构约束，其产出会复制该组织的沟通结构；系统架构与组织结构之间存在保结构的对应关系。它提示架构设计与组织设计必须协同。它把组织设计纳入架构决策的范畴。
MTH-I-03测试驱动开发方法论 methodology进阶测试驱动开发（TDD）是先写测试、再写实现、随后重构的开发技术，核心为红-绿-重构三步循环：先写一个失败的测试明确目标，再以最小实现使其通过，最后在测试保护下改善结构。
MTH-K-05事件响应与无指责复盘方法方法论 methodology进阶以明确的角色分工、活文档与显式交接组织事件响应，尽快缓解影响；事后以无指责复盘聚焦系统性成因、假设参与者基于当时信息善意行事，并把行动项闭环为可验证的改进。
ESS-N-02组织-架构同态本质 essence进阶组织沟通结构与其所设计系统的架构之间存在保结构的同态关系：沟通密集处趋于高内聚，沟通稀疏处趋于系统边界；若每个子系统各有独立设计组，两种结构几乎完全一致。
ESS-N-03团队边界与架构边界耦合本质 essence进阶团队边界与系统架构边界相互耦合：团队负责范围若与模块边界错位，跨边界协调成本会以接口复杂度、交接与返工的形式转嫁到系统上，二者需同步演化。
ESS-N-04认知负荷约束本质 essence基础团队能承载的复杂度有限，每一个新增的工具、职责或领域都消耗其心智带宽；认知负荷因此是划分团队与架构时必须显式考虑的约束，而非可忽略的软因素。
ESS-N-05组织即设计系统本质 essence高级承担系统设计的组织本身也是一个需要被设计的系统：其结构、边界、沟通与激励机制共同决定它能产出什么样的架构，因此组织设计应被视为技术设计的组成部分。
MTH-N-01逆向康威操作方法论 methodology进阶主动演进团队与组织结构，使其沟通结构对应期望的软件架构，从而让目标架构在组织沟通结构的塑形作用下自然生长，而非在既有组织形态下被扭曲。
MTH-N-02团队拓扑四类型方法论 methodology进阶把团队设计约束为四种基本形态——对齐价值流的团队、教练赋能团队、复杂子系统团队与平台团队——借成熟模式引导快速流动，同时以有限类型抑制组织设计的随意性。
MTH-N-03团队交互模式方法论 methodology进阶显式定义团队之间的交互方式——限时高带宽协作、清晰边界的服务消费、以及教练式促进——以消除含糊的协调要求，使团队边界的成本与收益可被管理。
MTH-N-04平台团队与最薄可行平台方法论 methodology进阶以产品方式建设平台团队，把通用能力封装为可自助使用的内部产品，以降低流对齐团队的认知负荷、加速交付；并以最薄可行平台约束平台规模，避免臃肿平台制造新依赖。
MTH-N-05DORA 交付效能指标方法论 methodology进阶以一组经过实证的软件交付效能指标——吞吐侧的变更前置时间、部署频率、失败部署恢复时间，与不稳定侧的变更失败率、部署返工率——衡量组织把变更交付到生产的效能，并用于改进而非考核。
MTH-N-06团队边界治理方法论 methodology高级把团队边界视为需要持续校准的活对象：以价值流、所有权、认知负荷与交付信号为依据，周期性评估并调整边界与交互方式，防止边界随组织惯性僵化或频繁漂移。
MTH-O-06粒度与边界设定方法论 methodology高级决定模块、服务、知识域与团队按什么分解、切到多细：应围绕可能变化的设计决策（信息隐藏）而非处理步骤切分，用内聚耦合度量与认知负荷约束边界，并使架构边界与团队边界同步演化。
MTH-O-09理解成本优先的简单原则方法论 methodology进阶这里的简单性指采用人们熟悉且前后一致的模式与结构，使新加入的工程师也能较快理解系统，而不是指功能数量少。书中把简单性列为可维护性的三根支柱之一，与可运维性、可演化性并列，理由很直接：维护成本占据软件生命周期支出的大头，而复杂度会让每一个改动系统的人都变慢，进而推高维护成本。判别困难也写得很诚实——是否简单带有主观成分，缺少客观刻度，因此同一个系统可以因为把复杂实现藏在简单接口之后而被认为简单，也可以因为实现本身直白却暴露大量内部细节而被认为复杂。所以简单性应作为设计目标显式提出，并接受它需要靠判断而非靠计数来裁定，也需要在评审中被反复追问，而不是默认它已经成立。
MTH-O-11度量与反馈闭环方法论 methodology高级建立轻量、客观、可复现的评估体系与反馈闭环：用真实场景与基线度量、以多指标协同避免单点失真，并把度量接入持续执行与复测；同时警惕古德哈特定律，防止指标一旦成为目标即被博弈。
MTH-H-04代码复审与可读性治理方法论 methodology进阶以评审流程把可读性与结构标准组织化、可教学地传播的治理方法：把代码评审从个人偏好检查转为有依据、有导师机制的常规活动，在变更合入前对结构、接口与可读性施加统一约束。
CAS-X-11Hermes 七层架构总览高级对八千余文件的工业级 AI Agent 项目做七层架构总览逆向，揭示其「越用越聪明」的自进化闭环如何在层间传导的控制型架构案例。
CAS-X-13Claude Code 架构逆向高级以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。
CAS-X-17技术知识中枢交付法高级从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。
CAS-X-18AI Agent 架构 DAG 复盘进阶对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
TEC-N-01交付效能度量与仪表化技术实践 technology进阶把交付效能指标的采集、聚合与呈现平台化：从版本控制与流水线事件自动计算并持续反馈，并以治理机制约束指标被博弈（gaming）的风险，使度量服务于改进而非考核。
TEC-N-02团队拓扑落地与规模化技术实践 technology高级在规模化组织中落地团队拓扑四类型与三交互模式，以认知负荷管理与快速流动为约束、显式定义团队交互方式的组织实践，用于把团队结构与被期望的架构对齐。
TEC-J-05部署自动化技术实践 technology进阶部署自动化把从构建产物到各环境的部署过程脚本化、参数化并纳入版本控制，使任何持有凭据者都能把任意已构建制品一致地部署到任意环境，且过程尽量幂等、可重复。
TEC-J-06部署流水线工具化技术实践 technology基础部署流水线把从提交到生产的构建过程拆分为多个置信度递增的自动化阶段，前一阶段产出的制品供后续阶段逐级晋级，生产部署通常是流水线的最后一个阶段。
TEC-K-03服务等级目标与错误预算技术实践 technology高级用 SLI（好事件/总事件）度量服务水平，设定小于 100% 的 SLO 目标，并以错误预算等于 100% 减 SLO 驱动发布与加固决策；SLA 则是含后果的对外契约。
TEC-K-05无指责复盘实践技术实践 technology进阶无指责复盘是一种事故发生后的书面复盘，其记录对象包括影响范围、处置与缓解过程、根因分析与后续行动项，而它的定义性特征在于聚焦方向：考察导致事件的那些系统性原因与当时的决策情境，而不是追查哪个个人或团队该被追究。它之所以被称为一种文化而不只是一份文档，是因为它同时规定了两件事——产出什么内容，以及以什么态度对待参与者。书中把它归入提升系统抵御人为失误能力的手段之列，与测试、回滚机制、渐进发布、监控与可观测性、界面设计并列，说明它的定位是组织层面的可靠性工程实践，而非单纯的行政流程。理解这一定义要抓住三组区分。
TEC-K-06DORA 交付指标技术实践 technology基础用一组软件交付效能指标衡量组织的交付吞吐与稳定性；当前官方口径为五项指标，由早期四键扩展而来，并已用失败部署恢复时间取代平均修复时间。
MTH-G-04领域驱动战略设计方法论 methodology高级以限界上下文显式划定模型适用边界、以通用语言在单个上下文内统一团队与代码的表达，并通过上下文映射管理跨上下文关系的领域建模战略方法。

§3组内关系图

横切·团队与康威 组内关系图前置依赖（prerequisite）：康威定律是组织-架构同态关系的原始表述前置依赖（prerequisite）：同态关系是团队-架构边界耦合的理论基础前置依赖（prerequisite）：认知负荷是划定团队边界的依据细化（refines）：同态机制细化了组织即设计系统的论断前置依赖（prerequisite）：组织设计须管理团队的认知负荷依据推导（derives_from）：逆向康威操作依据组织-架构同态关系依据推导（derives_from）：团队拓扑四类型依据认知负荷约束依据推导（derives_from）：交互模式设计依据团队边界耦合依据推导（derives_from）：平台团队以降低认知负荷为目的依据推导（derives_from）：交付效能指标度量组织作为设计系统的产出依据推导（derives_from）：团队边界治理依据边界耦合关系前置依赖（prerequisite）：逆向康威操作以团队拓扑为结构模板依赖关联（dependency）：团队类型须以交互模式定义协作细化（refines）：平台团队是四类型之一的专门化依赖关联（dependency）：平台团队主要采用服务消费交互依赖关联（dependency）：边界治理以团队拓扑为参照促成（enables）：交付效能指标为边界治理提供反馈信号对照（contrasts）：约束性模板与持续边界治理的张力张力冲突（conflicts）：平台服务化与高带宽协作需求的张力案例印证（case_instance）：印证：门控链与迭代反馈闭环案例印证（case_instance）：印证：组级视图加下钻的粒度控制实现（implements）：交付指标的自动采集与仪表化落地实现（implements）：交付度量平台实现持续反馈闭环实现（implements）：规模化组织中落地团队拓扑四类型实现（implements）：以最薄可行平台落地平台团队实现（implements）：以流动信号持续校准团队边界对照（contrasts）：仪表化平台区别于指标口径定义组合（combination）：度量反馈与团队拓扑落地协同促成（enables）：流水线为部署自动化提供载体组合（combination）：自动化与流水线配套落地实现（implements）：无指责复盘的文档化落地实现（implements）：DORA 交付效能指标的度量实现组合（combination）：错误预算与交付指标共同度量稳定与吞吐案例印证（case_instance）：印证：采集建模生成门控交付的阶段化交付流水线依据推导（derives_from）：DDD 边界与组织结构相互塑造（康威）团队拓扑四类型团队拓扑四类型（MTH-N-02）技术知识中枢交付法技术知识中枢交付法（CAS-X-17）AI Agent 架构 …AI Agent 架构 DAG 复盘（CAS-X-18）康威定律康威定律（ESS-N-01）组织-架构同态组织-架构同态（ESS-N-02）团队边界与架构边界耦合团队边界与架构边界耦合（ESS-N-03）认知负荷约束认知负荷约束（ESS-N-04）组织即设计系统组织即设计系统（ESS-N-05）领域驱动战略设计领域驱动战略设计（MTH-G-04）事件响应与无指责复盘方法事件响应与无指责复盘方法（MTH-K-05）逆向康威操作逆向康威操作（MTH-N-01）团队交互模式团队交互模式（MTH-N-03）平台团队与最薄可行平台平台团队与最薄可行平台（MTH-N-04）DORA 交付效能指标DORA 交付效能指标（MTH-N-05）团队边界治理团队边界治理（MTH-N-06）粒度与边界设定粒度与边界设定（MTH-O-06）度量与反馈闭环度量与反馈闭环（MTH-O-11）部署自动化部署自动化（TEC-J-05）部署流水线工具化部署流水线工具化（TEC-J-06）服务等级目标与错误预算服务等级目标与错误预算（TEC-K-03）无指责复盘实践无指责复盘实践（TEC-K-05）DORA 交付指标DORA 交付指标（TEC-K-06）交付效能度量与仪表化交付效能度量与仪表化（TEC-N-01）团队拓扑落地与规模化团队拓扑落地与规模化（TEC-N-02）
前置依赖实现依据推导案例印证对比冲突
横切·团队与康威：组内关系图（组内共 29 个成员，按度数裁剪展示 24 个）：内联 24 个节点、35 条组内边，连线按边类型着色（六类配色见下）；构建期确定性计算，无运行期脚本。

§4学习路径提示

本组内存在 5 条前置依赖边（prerequisite），推荐先掌握前置知识点，再进入依赖它的节点。

推荐阅读顺序（拓扑序）
Hermes 七层架构总览 → Claude Code 架构逆向 → 技术知识中枢交付法 → AI Agent 架构 DAG 复盘 → 领域驱动战略设计 → 代码复审与可读性治理 → 测试驱动开发 → 事件响应与无指责复盘方法 → 逆向康威操作 → 平台团队与最薄可行平台 → DORA 交付效能指标 → 团队边界治理 → 粒度与边界设定 → 理解成本优先的简单原则 → 度量与反馈闭环 → 部署自动化 → 部署流水线工具化 → 服务等级目标与错误预算 → 无指责复盘实践 → DORA 交付指标 → 交付效能度量与仪表化 → 团队拓扑落地与规模化 → 康威定律 → 团队拓扑四类型 → 组织-架构同态 → 团队交互模式 → 组织即设计系统 → 认知负荷约束 → 团队边界与架构边界耦合

入组前置依赖（组外节点 → 本组成员）

出组依赖（本组成员 → 组外节点）