几乎所有我喜欢的软件架构从业者都对该领域的任何一般规律深表怀疑。好的软件架构是非常特定于上下文的，可以分析在各种环境中以不同方式解决的权衡取舍。但如果他们都同意一件事，那就是康威定律的重要性和力量。重要到足以影响我遇到的每一个系统，并且足够强大，如果你试图与之抗争，你注定会失败。
该法的作者最好将其表述为： [1]
任何设计系统（定义广泛）的组织都将产生其结构是组织通信结构副本的设计。
——梅尔文·康威
康威定律本质上是观察到软件系统的架构看起来与构建它的开发团队的组织非常相似。最初对我的描述是，如果一个团队编写一个编译器，它将是一次编译器，但如果团队分成两个，那么它将是一个二次编译器。尽管我们通常就软件来讨论它，但这种观察通常广泛适用于系统。 [2]
正如我的同事 Chris Ford 对我说的：“Conway 明白软件耦合是由人类交流促成和鼓励的。”如果我可以轻松地与某些代码的作者交谈，那么我就更容易对这些代码建立丰富的理解。这使我的代码更容易与该代码交互，从而耦合到该代码。不仅在显式函数调用方面，而且在隐式共享假设和思考问题域的方式方面。
我们经常看到对法律的疏忽会如何扭曲系统架构。如果架构的设计与开发组织的结构不一致，那么软件结构中就会出现紧张关系。设计为简单明了的模块交互变得复杂，因为负责它们的团队不能很好地协同工作。甚至没有考虑有益的设计替代方案，因为必要的开发小组没有相互交谈。
一打或两个人可以进行深入和非正式的交流，因此康威斯法表示他们将创建一个整体。很好——所以康威定律不会影响我们对小团队的想法。当人类需要组织时，康威定律会影响决策。
处理康威定律的第一步是知道不要与之抗争。我还记得一位敏锐的技术领导者，他刚刚成为一个大型新项目的架构师，该项目由来自世界各地不同城市的六个团队组成。 “我做出了我的第一个建筑决定”他告诉我。 “将有六个主要子系统。我不知道它们会是什么，但会有六个。”
这个例子认识到位置对人类交流的巨大影响。将团队放在同一栋楼的不同楼层就足以显着减少沟通。将团队放在不同的城市和时区，进一步妨碍了常规对话。架构师认识到了这一点，并意识到他需要从一开始就在他的技术设计中考虑到这一点。在不同时区开发的组件需要具有明确定义且有限的交互，因为它们的创建者将无法轻松交谈。
与 Conways Law 的一个常见不匹配是，面向活动的团队组织跨目标工作以进行功能开发。由软件层（例如前端、后端和数据库）组织的团队导致占主导地位的PresentationDomainDataLayering结构，这是有问题的，因为每个功能都需要层之间的密切协作。类似地，按照生命周期活动（分析、设计、编码、测试）划分人员意味着从创意到生产需要大量的交接。
接受康威定律优于忽视它，在过去的十年中，我们已经看到了第三种方式来回应这条定律。在这里，我们故意改变开发团队的组织结构以鼓励所需的软件架构，这种方法被称为Inverse Conway Maneuver [3] 。这种方法在 微服务领域经常被谈论，倡导者建议建立小型、长寿的BusinessCapabilityCentric团队，其中包含交付客户价值所需的所有技能。通过以这种方式组织自治团队，我们利用康威定律来鼓励类似的自治服务，这些服务可以相互独立地增强和部署。事实上，这就是为什么我将微服务主要描述为构建开发组织的工具。
| 忽视 | 不要考虑康威定律，因为你从未听说过它，或者你认为它不适用（旁白：它确实适用） |
| 接受 | 认识到康威定律的影响，并确保您的架构不会与设计师的沟通模式发生冲突。 |
| 逆康威机动 | 改变设计人员的沟通模式以鼓励所需的软件架构。 |
领域驱动设计在这里可以起到帮助定义组织结构的作用，因为 DDD 的一个关键部分是识别BoundedContexts 。有界上下文的一个关键特征是它有自己的UbiquitousLanguage ，由在该上下文中工作的人定义和理解。这样的环境形成了围绕一个主题对人们进行分组的方式，然后可以与价值流保持一致。
关于康威定律，要记住的关键是系统的模块化分解和开发组织的分解必须一起完成。这不仅仅是开始，架构的演变和人类组织的重组必须在企业的整个生命周期中齐头并进。
延伸阅读
认识到康威定律的重要性意味着崭露头角的软件架构师需要考虑 IT 组织设计。关于这个主题的两本有价值的书是 Narayan 的敏捷 IT 组织设计和 Skelton 和 Pais 的团队拓扑。
致谢
Bill Codding、Birgitta Boeckeler、Camilla Crispim、Chris Ford、Gabriel Sadaka、Matteo Vaccari、Michael Chaffee 和 Unmesh Joshi 审查了本文的草稿并提出了改进建议