几乎所有我所青睐的软件架构从业者都对这个领域的任何一种一般法则都深表怀疑。好的软件架构是非常特定于上下文的，分析在各种环境中以不同方式解决的权衡。但是，如果他们都同意一件事，那就是康威定律的重要性和力量。它足够重要，足以影响我遇到的每个系统，也足够强大，如果你试图对抗它，你注定要失败。
该法律的作者可能最好将其表述为：
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
任何设计系统（广义定义）的组织都会产生一个设计，其结构是组织通信结构的副本。——梅尔文·康威
康威定律本质上是这样一种观察，即软件系统的架构看起来与构建它的开发团队的组织非常相似。最初有人向我描述说，如果一个团队编写一个编译器，它将是一个单遍编译器，但如果团队分为两个，那么它将是一个双遍编译器。虽然我们通常在软件方面讨论它，但这种观察结果广泛适用于一般的系统。
正如我的同事克里斯·福特（Chris Ford）对我说的那样：“康威明白，软件耦合是由人类交流实现和鼓励的。如果我能轻松地与一些代码的作者交谈，那么我就更容易建立对该代码的丰富理解。这使我的代码更容易与该代码进行交互，从而与该代码耦合。不仅在显式函数调用方面，而且在隐含的共享假设和对问题域的思考方式方面。
我们经常看到对法律的忽视会扭曲系统架构。如果架构的设计与开发组织的结构不一致，那么软件结构中就会出现紧张关系。设计为简单明了的模块交互变得复杂，因为负责它们的团队不能很好地协同工作。甚至没有考虑有益的设计替代方案，因为必要的开发团队没有相互交流。
十几个人可以进行深入和非正式的交流，因此康威律师事务所表示他们将创建一个整体。这很好，所以康威定律不会影响我们对小型团队的思考。当人类需要组织时，康威定律应该影响决策。
处理康威定律的第一步是知道不要与之抗争。我还记得一位敏锐的技术领导者，他刚刚被任命为一个大型新项目的建筑师，该项目由世界各地不同城市的六个团队组成。“我做出了我的第一个建筑决定，”他告诉我。“将有六个主要的子系统。我不知道它们会是什么，但会有六个。
这个例子认识到了位置对人类交流的巨大影响。将团队放在同一栋楼的不同楼层足以大大减少沟通。将团队放在不同的城市和时区，进一步妨碍了常规对话。建筑师认识到了这一点，并意识到他需要从一开始就在技术设计中考虑到这一点。在不同时区开发的组件需要具有明确定义且有限的交互，因为它们的创建者无法轻松交谈。
与康威定律的一个常见不匹配是，面向活动的团队组织在跨目的下工作以进行功能开发。按软件层（例如前端、后端和数据库）组织的团队会导致占主导地位的 PresentationDomainDataLayering 结构，这是有问题的，因为每个功能都需要层之间的密切合作。同样，按照生命周期活动（分析、设计、编码、测试）划分人员意味着要获得从想法到生产的大量交接。
接受康威定律比忽视它要好，在过去的十年里，我们看到了第三种回应康威定律的方式。在这里，我们特意改变开发团队的组织结构，以鼓励所需的软件架构，这种方法被称为逆康威机动[4]。这种方法在微服务领域经常被谈论，倡导者建议建立小型的、长期存在的以业务能力为中心的团队，其中包含交付客户价值所需的所有技能。通过以这种方式组织自治团队，我们采用康威定律来鼓励类似的自治服务，这些服务可以相互独立地增强和部署。事实上，这就是为什么我将微服务描述为主要构建开发组织的工具。
| |
| |
| Ignore | Don’t take Conway’s Law into account, because you’ve never heard of it, or you don’t think it applies (narrator: it does)
不要考虑康威定律，因为你从未听说过它，或者你认为它不适用（旁白：确实如此） |
| Accept | Recognize the impact of Conway’s Law, and ensure your architecture doesn’t clash with designers’ communication patterns.
认识到康威定律的影响，并确保你的架构不会与设计师的沟通模式发生冲突。 |
| Inverse Conway Maneuver 逆康威机动 | Change the communication patterns of the designers to encourage the desired software architecture.
改变设计人员的沟通模式，以鼓励所需的软件架构。 |
虽然逆康威机动是一个有用的工具，但它并不是万能的。如果您有一个具有僵化架构的现有系统，并且想要更改，那么更改开发组织不会立即解决。相反，它更有可能导致开发人员和代码之间的不匹配，从而为进一步增强增加摩擦。对于这样的现有系统，康威定律的要点是，我们需要在更改组织和代码库时考虑它的存在。像往常一样，我建议采取一些小步骤，同时对反馈保持警惕。
领域驱动设计在康威定律中发挥着帮助定义组织结构的作用，因为 DDD 的一个关键部分是识别 BoundedContexts。边界上下文的一个关键特征是它有自己的 UbiquitousLanguage，由在该上下文中工作的一群人定义和理解。这样的背景形成了围绕一个主题对人们进行分组的方式，然后可以与价值流保持一致。
关于康威定律，要记住的关键是，系统的模块化分解和开发组织的分解必须一起完成。这不仅仅是在开始，架构的演变和人类组织的重组必须在企业的整个生命周期中齐头并进。
