定义康威定律的正确方法

Question

首先我想知道康威定律是指组织的物理结构或组织中的关系结构，其次我不明白福勒在他的文章中是什么意思：

在将大型应用程序拆分为多个部分时，管理层通常侧重于技术层，从而导致 UI 团队、服务器端逻辑团队和数据库团队。当团队沿着这些线分开时，即使是简单的更改也可能导致跨团队项目需要时间和预算批准。一个聪明的团队将围绕这一点进行优化，并为两害取其轻——只需将逻辑强加到他们有权访问的任何应用程序中。换句话说，到处都是逻辑。这是康威定律[5] 的一个实例。

Answer 1

我开始回答问题的第二部分。 Fowler 想说的是，或者我的理解是，当需要将项目拆分为多个部分（例如将单体拆分为微服务）时，您可能会面临将大团队拆分为较小团队的问题，而您围绕业务技能或能力来做，而不是围绕技术。

如果您的公司按技能或技术层对人员进行分组，您将拥有一个 devops 团队、一个前端团队、一个后端团队，并且没有人能够处理单个项目：这将迫使你有一个孤立的应用程序（又名单体应用程序），因为每个团队相互依赖才能完全完成需求，并且扩展将非常困难。当您雇用新的 devops 时，您只会增加 devops 团队的规模。当你添加一个新特性时，你只会增加你的单体大小。这就是康威所说的关系。

另一方面，如果您通过混合所有这些技术并创建自给自足的团队来组织您的公司，那么每个团队将由例如 1 个 devops、2 个后端和 1 个前端组成。现在，您实际上可以将您的单体应用拆分为微服务，并根据需要进行扩展。当您需要新的微服务时，您可以创建一个全新的团队，理想情况下没有人会受到此操作的影响。

我同意 David 的观点，他说沟通很重要，但必须以正确的方式提供。