领域驱动设计在康威定律中发挥作用，帮助定义组织结构： 因为 DDD 的一个关键部分是识别BC：BoundedContexts。 BC一个关键特征是它有自己的UL：UbiquitousLanguage，由在该上下文中工作的人定义和理解。 这样就可以围绕一个主题对人员进行分组的方式，与价值流保持一致。
几乎所有好的软件架构从业者都对该领域的任何一种普遍规律深表怀疑。
好的软件架构是非常具体的，它分析了在各种环境中以不同方式解决的权衡。
但如果有一件事他们都同意的话，那就是康威法则的重要性和力量。
它的重要性足以影响到我所遇到的每一个系统，而且强大到如果你试图对抗它，你就注定要失败。
作者可能对其进行了最好的阐述：
任何组织在设计一个系统（广义的定义）时，都会产生一个设计，其结构是该组织的通信结构的副本。
-- 梅尔文-康威
康威定律本质上是一种观察，即软件系统的结构看起来与构建它的开发团队的组织非常相似。
最初我对它的描述是：如果一个团队编写一个编译器，它将是一个单通道编译器，但如果这个团队被分成两个，那么它将是一个双通道编译器。
虽然我们通常是针对软件来讨论的，但这个观点广泛适用于一般的系统。
正如我的同事克里斯-福特对我说的那样。"康威明白：软件耦合是由人与人之间的交流所促成和鼓励的"。
如果我可以轻松地与一些代码的作者交谈，那么我就更容易对该代码建立起丰富的理解。这使得我的代码更容易与该代码进行交互，从而被耦合起来。不仅仅是在明确的函数调用方面，而且在隐含的共享假设和对问题领域的思考方式方面。
我们经常看到不注意这个规律会扭曲系统架构：如果一个架构的设计与开发组织的结构不一致，那么软件结构中就会出现紧张。
原本设计得很简单的模块交互变得很复杂，因为负责这些模块的团队不能很好地合作。
有利的设计方案甚至没有被考虑，因为必要的开发小组没有相互交流。
十几个人或两个人可以进行深入而非正式的交流，所以康威法则表明他们会创造出一个单体。
这很好--所以康威定律并不影响我们对小型团队的思考。当人类需要组织起来的时候，康威法则才应该影响决策。
处理康威法则的第一步是知道不要与之对抗
我还记得一位敏锐的技术领导，他刚刚成为一个大型新项目的架构师，该项目由分布在世界各地不同城市的六个团队组成。"他告诉我："我做出了我的第一个架构决定。"将有六个主要的子系统。我不知道它们会是什么，但它们会有六个。"
这个例子认识到位置对人类交流的巨大影响。把团队放在同一栋楼的不同楼层，就足以大大减少沟通。把团队放在不同的城市和时区，进一步阻碍了正常的对话。
架构师认识到这一点，并意识到他需要从一开始就在技术设计中考虑到这一点。在不同时区开发的组件需要有一个明确的和有限的互动，因为它们的创造者将不能轻易地交谈。
一个常见的与康威法则不匹配的情况是，面向活动的团队与功能开发交叉进行。按软件层（如前端、后端和数据库）组织的团队会导致主导的PresentationDomainDataLayering结构，这是有问题的，因为每个功能都需要各层之间的密切协作。同样，按照生命周期活动（分析、设计、编码、测试）来划分人员，也意味着要有大量的交接工作才能将一个功能从想法变成生产。
接受康威定律比忽视它要好，在过去的十年中，我们看到了应对这一定律的第三种方式。
在这里，我们故意改变开发团队的组织结构，以鼓励所需的软件架构，这种方法被称为反康威机动法。
这种方法在微服务的世界里经常被谈论，倡导者建议建立小型的、长期存在的、以业务能力为中心的团队，这些团队包含提供客户价值所需的所有技能。
通过这样组织自治团队，我们采用康威法则来鼓励类似的自治服务，这些服务可以独立地被增强和部署。事实上，这就是为什么我把微服务描述为主要是一种构建开发组织的工具。
对康威法则的三种反应
- 视而不见： 不要考虑康威定律，因为你从来没有听说过它，或者你认为它不适用。
- 接受：认识到康威法则的影响，并确保你的架构不会与设计师的沟通模式发生冲突。
- 逆康威： 改变设计者的沟通模式，鼓励所需的软件架构。
虽然逆康威法则是一个有用的工具，但它并不是万能的。如果你有一个现有的系统，有一个僵化的架构，而你想改变它，改变开发组织并不会是一个即时的解决方案。相反，它更有可能导致开发人员和代码之间的不匹配，为进一步的改进增加摩擦。对于这样一个现有的系统，康威定律的意义在于，我们需要在改变组织和代码库的同时考虑到它的存在。像往常一样，我建议采取小步骤，同时对反馈保持警惕。
领域驱动设计在康威定律中发挥作用，帮助定义组织结构： 因为 DDD 的一个关键部分是识别BC：BoundedContexts。 BC一个关键特征是它有自己的UL：UbiquitousLanguage，由在该上下文中工作的人定义和理解。 这样就可以围绕一个主题对人员进行分组的方式，与价值流保持一致。