康威定律与微服务拆分
系统复印的是组织沟通结构，不是目标架构图
Melvin Conway 在 1968 年发表于 Datamation 的《How Do Committees Invent?》给出这条定律的原始表述：设计系统的组织受约束， 必然产出其组织沟通结构的复制品；「康威定律」这个名字是 Fred Brooks 在《人月神话》里起的。论文里有机制层面的论证： 系统里两个模块相连，对应的设计组必然协商过接口规范，而接口协商是设计活动里最重的沟通成本，所以谁跟谁开会， 决定哪些模块焊在一起。沟通密的地方服务边界变薄，最后焊成一对互相等待的服务；沟通稀的地方边界变厚， 独立演进才站得住。Eric Raymond 的直观化流传最广：4 个团队做一个编译器，会得到一个 4 遍处理的编译器。 中文社区常把定律收成四条（沟通写进设计、系统做不到一次完美、组织与系统趋向同构、组织变大系统拆开）， 四条是同一件事的四个侧面：结构跟着人走。因果方向不能倒：组织是因，服务图是果，先画服务清单再倒推组织， 上线三个月架构图就会变回组织图。
见：Committees Paper（Conway 官网原文）、Conway's Law - Martin Fowler
三种错拆复印的是错误的那张组织图
按行政部门拆、按技术层拆、按数据库表拆，是最常见的三种错拆，共同点是复印了一张错误的图：按部门拆， 部门墙变成服务墙，一笔业务要穿三道墙；按技术层拆出控制器服务、业务服务、数据服务，一次改动三个仓库一起发， 独立部署名存实亡；按表拆则一张表一个服务，表和表有外键，服务和服务就有聊天式调用。 正确的复印对象是交付单元：谁一起改、一起发、一起值班。交付单元对不上行政部门时，就不要按行政部门切。 判断一刀真假的最硬标准在数据上：切开之后还要共用一张表，这刀是假的，先把表所有权收清再谈拆分。
单一职责看变化轴，粒度看变化同步与过网沟通
单一职责落到服务上，不是一个服务只干一件小事，而是一个服务只有一个变化的理由：促销规则改了不该打开库存仓库， 库存盘点规则改了不该打开订单仓库。判法很具体：看过去两个月哪些提交总是成对出现，成对出现的模块先合并成一个边界， 再谈拆；反过来一个服务里两拨人改两件无关的事，就该切开。粒度看两个数：变化是否同步、沟通是否过网， 变化同步且沟通不过网时留在一个服务里更便宜，不同步且必须过网才拆得独立。现场信号是调用比重： 两个服务之间的调用大过对其他服务之和，这对服务就在聊天，粒度已经偏细，聊天式调用修不好就并回去， 不要加缓存硬撑。反直觉的是服务变多不等于交付更快：两支团队守十二个服务，每人同时挂三个仓库， 上下文切换吃掉并行，一次需求穿五个服务，联调比单体还长；服务数不该长期大于能独立交付的团队数， 没人认领的服务会逼出全员会，定律又把系统拉回原点。
切之前的三问，卡住任一条就回模块化单体
落地只问三个问题：这刀下去哪一支团队日夜守它；它独立变化的理由是什么、过去两个月成立过几次； 切开之后跨边界的沟通能不能变成接口或事件。三问配三条规矩：一个团队最多死守一个对外发布的服务， 内部模块可以多、对外进程保持少；先在模块里验证变化轴，再搬到独立进程，模块都守不住的边界上网之后更守不住； 出现聊天式调用优先合并，而不是加网关和重试，网关和重试会把粒度错误藏起来。 组织侧的对齐手法是逆康威机动：想要几个独立服务，先组几支能独立交付的团队，再把代码边界推到团队边界上， 真拆分的标志是出了问题知道找哪支团队、不拉全员会。Team Topologies 把这套组织设计工程化为认知负载度量、 四类团队与三种交互模式，与单体拆分时机（该不该拆）互为上下游：时机管立案，三问管下刀的位置。
见：Team Topologies Key Concepts
Bezos API Mandate 是组织级接口化强制的史前案例
2002 年的 Amazon 还是内部代号 Obidos 的巨型单体，各团队为赶工互相直连对方的数据库。Bezos 发出一页备忘录： 所有团队的功能只准通过 service interface 暴露、一切沟通必须走接口、禁止直接链库读库、禁止共享内存、 技术栈随便选、不照做的人离开。这份备忘录原文从未公开，流传版本来自 Steve Yegge 2011 年意外泄露的内部帖转述， 真实性存在争议（Nordic APIs 等曾提出真 memo 还是神话的质疑），但指令与 Amazon 服务化架构、AWS 崛起的时间线 吻合是公认事实。它的机制是强制「沟通必须过网」：拆分三问里最难的跨边界沟通接口化，被用行政命令组织级执行， 真实沟通图被改写成星型接口图后，系统自己长成了服务化。反面教材是学 SOA 只学一半的公司：接口建了后门留着， 共表、直连库、绕网关调用让沟通图里全是密边，复印出来的是假接口真耦合的分布式单体。评审拆分方案时 先查有没有后门，Mandate 真正的执行红线不是要有接口，而是不许有别的路。
见：The Bezos API Mandate - Nordic APIs、API Mandate - Kong
Spotify Model 失败在抄了名义图，没换沟通图
2012 年 Spotify 发布 engineering culture 视频，介绍 squad、tribe、chapter、guild 的组织设计，此后十年它是 史上被模仿最多的组织模型，管理咨询公司靠「Spotify 转型」赚了无数钱。而 Spotify 自己从未完整运作过这个模型， 前员工 Jeremiah Lee 2017 年公开证言《Spotify doesn't use the Spotify model》，多篇复盘确认公司后来实质放弃了它。 失败机制出在模仿者身上：复印的是视频里的名义组织图（小队自治、矩阵双线），squad 之间的真实沟通却没同步改造， 接口协调、发布对齐的协调会一个没少，真实沟通图还是网状，系统长出来还是网状耦合，跨 tribe 依赖失控， chapter 经理的职能线与 squad 的使命线天天拉扯优先级。这正是逆康威只做了一半的形态：换了名义图、没换沟通结构， 定律照样运转，复印出的还是旧沟通图的产物。移植任何组织框架前先问：这个框架改变的是名义图还是沟通图， 只动名义图的改造，调用图三个月爬回原样。
见：Why Spotify Squads Are a Popular Failure - Chameleon、The Spotify Model Explained - Peerdom