康威定律×海勒姆定律
两条元定律 // 系统的真实形态不由设计者决定
> 康威说：组织决定架构；海勒姆说：用户决定契约。两条定律指向同一个元洞察——系统的真实形态，不由设计者的意图决定，而由它与环境的耦合决定。
Two Laws — 两条元定律
Any organization that designs a system will produce a design whose structure is copied from the organization's communication structure.— Melvin Conway《How Do Committees Invent?》
来源：1968 年 4 月 Datamation。康威 1967 投稿《哈佛商业评论》被拒，转投 Datamation 发表；后因 Fred Brooks 在《人月神话》引用而广为人知。
含义：系统架构是组织沟通结构的"复印件"。团队怎么沟通、边界划在哪，代码就怎么耦合、模块就怎么分。
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.— Hyrum Wright
来源：海勒姆·赖特（Hyrum Wright，Google 软件工程师），基于 Google 大规模 API 使用观察，正式收录于《Software Engineering at Google》第 1 章。
含义：API 用户够多时，返回顺序、超时、缓存、甚至 bug 这些"非契约行为"都会被某人依赖，变成事实契约——你再也不能改。
Weld — 设计者的承诺，会被现实改写
康威：设计者想要的架构，被组织结构改写。
海勒姆：设计者承诺的契约，被用户行为改写。
意图是草图，耦合才是成品。一条针对"开发期"（谁和谁说话决定代码怎么连），一条针对"运行期"（谁在用你决定你能改什么）——合起来覆盖了系统的整个生命周期。
Simulate — 两条定律，动手感受
康威 · 组织结构 → 系统架构 // 切换团队形态，看架构如何被"复印"
海勒姆 · 用户数 → 事实契约 // 拖动用户数，契约外行为逐个被"依赖"
A · 官方方法
B · 官方方法
↑ 文档承诺的契约（始终稳定）
Personal Takeaways — 个人启示 · 03
01
意图不是结果
架构是组织的影子，契约是用户的依赖。设计者画在白板上的"意图"，会被组织怎么沟通、用户怎么使用一层层改写。评估一个系统，别只看设计文档，要看它长在什么样的组织和使用环境里。
02
改系统，要先改环境
逆康威定律：想要微服务架构，先拆跨职能团队；想要可演进的 API，先管理"可观察行为"。真正的杠杆往往在系统之外（组织结构、用户生态），死磕代码反而收效甚微。
03
耦合是双向负债
康威揭示组织耦合进架构，海勒姆揭示用户耦合进实现——两种耦合都让"改动"变贵。识别耦合面（哪些团队边界、哪些可观察行为被依赖），比优化代码本身更决定一个系统能活多久。