1. 一个具体问题
订单团队说自己的接口已经完成，库存团队也说没有问题，但一个简单的退货流程要跨四个负责人才能修改。架构图上的服务边界非常整齐，用户操作却到处中断。这时问题可能不只在代码：团队之间如何讨论需求、承担责任，也参与塑造了系统。
2. 一句话解释
组织的沟通结构会约束它能够设计出的系统结构，改变架构通常也需要改变协作方式。
3. 出处与原意
Melvin Conway 在 1968 年的《How Do Committees Invent?》中提出这一观察；Brooks 后来称之为康威定律。原文讨论广义的系统设计组织，并不限于微服务。它描述组织与设计之间的约束关系，不是要求按部门名称机械地拆分服务。
4. 原理与机制
接口是一组需要共同理解的承诺，承诺的形成依赖人际沟通。一个团队内部容易统一术语和优先级，跨团队则要安排会议、协调排期，于是软件往往在组织边界形成协议、复制数据或等待流程。反过来，已有系统也会决定谁必须经常协作。这种相互作用能让错误边界自我延续：跨界修改越困难，团队越倾向局部修补，整体一致性就越差。设计团队拓扑时，应观察实际信息流，而不只看汇报线。
组织调整也有过渡成本。把人员重新分组后，旧的权限、预算、考核和发布流程若仍按原边界运行，实际沟通结构可能没有改变。判断是否完成调整，应查看一项需求能否由同一组人形成共同理解、作出必要决定并获得反馈。短期跨职能协作可以用来发现边界，随后再确定长期责任，避免每遇到一个问题就重画组织图。
5. 一个完整案例
假设案例：商城把“退货审核”交给客服团队，把“库存回补”交给仓库团队，两者使用不同退货编号。每次修改审核状态都要两边排期，结果出现重复回补。方案不是立即把服务全部合并，而是组建临时跨职能小组，共同定义退货状态机和唯一事件编号，再由明确的业务负责人维护契约。小组用一次端到端退货作为验收单元，记录跨团队等待天数。若等待减少且重复问题消失，说明边界和沟通的调整确实帮助了设计。
6. 适用条件与反例
这一视角适合解释反复出现的接口扯皮、跨部门需求积压和局部最优。它不能单独证明某种组织结构最好：安全隔离、性能和法规约束也可能要求技术边界不同于团队边界。小团队也可能维护多个稳定组件，大团队也可以依靠清晰契约共同维护一个系统。
7. 今天可以尝试的行动
选一项最近交付缓慢的用户流程，画出它经过的模块和真实沟通对象。标出每次“等另一个团队确认”的位置，再挑一个等待最久的接口，安排双方共同定义输入、失败语义和验收负责人。先用一次小改动验证边界，再决定是否重组。