【架构思考】康威定律的解读与实践

定律

马尔文·康威1967年提出：“设计系统的架构受制于产生这些设计的组织的沟通结构。”
换句话说：“如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系，那么项目将会遇到麻烦。因此，应该确保组织结构兼容于产品架构。”

随着业务的发展与架构的演进，我对于康威定律有了更深刻的理解。

现状

组织架构如下：

应用架构如下：

简单地说，两个不同的部门B，C，共同开发维护了一个大的项目。而部门B（名义上的）主要工作，是大项目中的一个子模块 sub process 3.3 。部门C是负责其它模块。

（实际上，由于模块之间高度的耦合性，部门B的人员可能会改动所有模块。）

说明：module 3 的代码量占整个大项目的80%，而 sub process 3.3 占 module 3的30%。

问题

这样做明显有几个问题：

强耦合： module 3 内的几个子流程高度耦合，（没有丰富的经验）很难保证只改动 sub process 3.3 而不会影响到其它。

无法快速迭代：改动一个 sub process 3.3 ，必须启动整个长链路的应用，测试麻烦导致开发周期长。

相互制约发展：sub process 3.3和其它 module 3 子流程，由于在一个模块内，必须保持一致性。比如要想采用了一个新的技术栈，必须两者都同意，有时会相互掣肘。

权责不明确：部门B（有些时候不得不）改动其它模块时，因为不算在KPI里，有可能简单应付了事而导致代码质量下降。

解决

根据康威定律，想要解决问题，系统架构和沟通架构，必须有一个发生改变，向另一个靠拢。所以，哪一个改动成本小，就改哪个。
这里，我们选择的是改动系统架构。

新的应用架构如下：

sub process 3.3 放到了最后面，接在了持久化层之后。

这样，它虽然还是长链路中的一环，但是，有几个好处。

• 首先，代码完全和 module 3 解耦，不会互相影响。
• 其次，开发和测试阶段可以从持久层还原数据，不需要跑前面1-5个模块。只有在最后 regression 测试的阶段才需要跑整个链路，不过这时候代码已经稳定了。
• 另外，整个模块重构的时候升级为微服务架构，方便后续扩展。

在实际执行的阶段，还是遇到了一些阻力：

• 重构可能导致整个链路的处理时间延长，需要加入一些优化。
• 对于拆分模块导致服务分散化的担忧。

整个重构的过程也不是一蹴而就的，需要大量反复讨论，POC，利益平衡，才能一步一步往下走。