康威定律

我所推崇的几乎所有软件架构实践者都对该领域任何形式的普遍规律深表怀疑。优秀的软件架构非常依赖于具体情况，需要分析在各种环境中产生不同结果的权衡取舍。但如果说他们都同意的一点，那就是康威定律的重要性及其影响力。它对所有我遇到的系统都产生了重大影响，其影响力之大，以至于如果你试图与之抗衡，你注定会失败。

该定律的最佳表述可能来自其作者，如下所示：[1]

任何设计系统（广义定义）的组织，其产生的设计结构都将复制该组织的沟通结构。

-- 梅尔文·康威

康威定律本质上是观察到软件系统的架构与构建该系统的开发团队的组织结构惊人地相似。最初向我描述它时，人们说，如果一个团队编写一个编译器，它将是一个单遍编译器，但如果团队被分成两个，那么它将是一个两遍编译器。虽然我们通常在软件方面讨论它，但这种观察结果广泛适用于一般系统。 [2]

正如我的同事克里斯·福特对我说：“康威理解，软件耦合是由人类沟通实现并鼓励的。”如果我能轻松地与某些代码的作者交谈，那么我更容易对该代码建立深入的理解。这使得我的代码更容易与该代码进行交互，从而耦合在一起。不仅在显式函数调用方面，而且在隐式共享假设和解决问题域的方式方面也是如此。

我们经常看到，忽视该定律会导致系统架构扭曲。如果设计的架构与开发组织的结构不一致，那么软件结构中就会出现紧张局势。原本设计为简单的模块交互变得复杂，因为负责它们的团队无法很好地协作。有益的设计方案甚至没有被考虑，因为必要的开发组之间没有沟通。

一二十个人可以进行深入的非正式沟通，因此康威定律表明他们会创建一个整体。这很好 - 因此康威定律不会影响我们对小型团队的思考。当人类需要组织时，康威定律应该影响决策。

处理康威定律的第一步是知道不要与之抗衡。我仍然记得一位敏锐的技术领导者，他刚被任命为一个大型新项目的架构师，该项目由六个团队组成，这些团队分布在世界各地的不同城市。“我做出了我的第一个架构决策，”他告诉我。“将有六个主要子系统。我不知道它们将是什么，但将有六个。”

这个例子认识到位置对人际沟通的重大影响。将团队安排在同一建筑物的不同楼层足以显着减少沟通。将团队安排在不同的城市和时区，更会阻碍常规对话。这位架构师认识到这一点，并意识到他需要从一开始就在技术设计中考虑这一点。在不同时区开发的组件需要具有明确定义且有限的交互，因为它们的创建者无法轻松地进行沟通。 [3]

康威定律的一个常见不匹配之处在于，活动导向的团队组织与功能开发背道而驰。按软件层（例如前端、后端和数据库）组织的团队会导致占主导地位的表示层-领域层-数据层结构，这存在问题，因为每个功能都需要层之间紧密协作。类似地，按生命周期活动（分析、设计、编码、测试）划分人员意味着需要进行大量交接才能将功能从想法转变为生产。

接受康威定律比忽视它要好，在过去十年中，我们看到了应对该定律的第三种方式。在这里，我们故意改变开发团队的组织结构，以鼓励所需的软件架构，这种方法被称为逆康威操作 [4]。这种方法在微服务领域经常被提及，倡导者建议构建小型、长期存在的以业务能力为中心的团队，这些团队包含提供客户价值所需的所有技能。通过以这种方式组织自治团队，我们利用康威定律来鼓励类似的自治服务，这些服务可以独立于彼此进行增强和部署。事实上，这就是我将微服务描述为主要用于构建开发组织的工具的原因。

虽然逆康威操作是一个有用的工具，但它并非万能。如果你有一个现有的系统，其架构非常严格，你想改变它，改变开发组织不会立即解决问题。相反，它更有可能导致开发人员和代码之间出现不匹配，从而给进一步的增强带来摩擦。对于这样的现有系统，康威定律的意义在于，我们需要在改变组织和代码库时考虑它的存在。像往常一样，我建议采取小步骤，同时注意反馈。

领域驱动设计与康威定律一起发挥作用，帮助定义组织结构，因为 DDD 的一个关键部分是识别限界上下文。限界上下文的一个关键特征是它拥有自己的通用语言，由在该上下文中工作的人员定义和理解。这些上下文形成了围绕主题对人员进行分组的方式，然后可以与价值流保持一致。

关于康威定律，需要记住的关键一点是，系统的模块化分解和开发组织的分解必须同时进行。这不仅仅是在开始时，架构的演变和人类组织的重组必须在整个企业生命周期中同步进行。