英国议会下议院在1941年的闪电战中被摧毁后，上议院就如何重建下议院展开辩论。
一些人认为这是向马蹄形 "架构 "转变的机会，但丘吉尔团队主张他们保留 "对抗性的长方形架构"。他认为，这种布局本身就是英国两党制度的催化剂。议员们要么站在一方，要么站在另一方，没有中间环节。人们必须在众目睽睽之下走过地板，以防他们想换边。
沟通塑造架构
我们的架构结构方式影响着我们的沟通方式，而我们的沟通方式又影响着我们的建造方式。也许丘吉尔的想法是康威法则的前身：
任何设计一个系统（广义的）的组织都会产生一个设计，其结构是该组织的沟通结构的副本。
- 梅尔文-康威
这个想法是，软件架构看起来与建造它的开发团队的组织非常相似。
这引起了我的思考，我不禁反思了Hyperswitch架构的演变。我的团队的沟通是如何影响设计决策的？对于一个支付基础设施产品来说，什么才是正确的架构？
一旦决定用Rust构建和开源项目，我们就开始构建Hyperswitch了。少数开发者面对面进行高频率的非正式互动是可能的。康威定律表明，他们会创造出一个单体，而这正是我们开始时的情况。
我们在Ferris House（是的，我们的办公室以Rust吉祥物命名）工作，一楼有三个房间，一楼有两个房间。我们是一个15人的团队，在早期，整个开发团队都在一楼工作。
在这个阶段，我们想开始建立SDK。这个SDK将是客户应用程序和Hyperswitch后台之间的接口。这也将为客户提供一个可定制的跨越多个支付处理器的统一结账体验。我们还需要一个仪表盘，供商家配置他们的连接器（支付处理器）和管理他们的支付业务。我们决定利用我们母公司的React团队（在同一个社区的不同办公室工作）来建立SDK和仪表板。这也是我们决定将整个团队组织成3个pod的时候。Pod 1将建立Rust后端，Pod 2将建立SDK，Pod 3将负责仪表盘的工作。
也许这就是我们的 "反康威机动"。在这种情况下，理想的软件架构是将SDK和开放的核心后端脱钩，以便独立开发两者。因此，我们自然而然地走向了3个pod 的结构，我们现在是一个大约35人的团队。
此外，产品的价值在很大程度上取决于我们支持多少个连接器（支付处理器）。
这意味着我们需要一种方法来扩展我们的连接器（支付处理器）集成过程。我们需要改进集成过程，以便使开源贡献者能够轻松参与。因此，Pod 4诞生了，连接器模块（部分）从核心中分离出来，这样，从事集成工作的开发人员需要最小的核心环境。团队壮大了一些，Ferris House也开始满员了。我们现在占据了两层楼的所有房间。每个单元都有自己的房间，单元之间的交流主要由各自的PM负责。
这个架构是如催生了团队的结构的。我能够（回顾性地）看到紧密耦合的部分是如何由经常相互沟通的开发人员建立的。这也表明了我们的发展方向。
最终，从事连接器工作的团队会有一个独立的发布周期，不会依赖核心部件的部署。
架构是分形的
pod之间的通信影响了高层架构，pod内部的通信影响了组件级架构。
一个有效的复杂系统无一例外地是由一个有效的简单系统演变而来。
- 盖尔定律
一个复杂的系统不能从头开始设计并使之工作，这个观点被低估了。那么，如果康威定律适用于一个系统在高层次上的工作方式，它是否也适用于其子系统？我们不能不赞赏工程师之间在最原子水平上的沟通性质的重要性。
也许我们正朝着我们最大的反康威演习前进：完全承认并接受康威法则，以确保架构不会与团队的沟通模式发生冲突。
随着我们的应用程序的增长和变得更加复杂，我们发现自己需要进一步模块化。
我们把自己分割成面向领域的模块，在内部分层。我们甚至搬到了一个新的办公室，这只是一个可以容纳我们所有人的大房间。
所有的区块都代表了各个团队，它们几乎是模仿应用程序的架构。尽管这看起来只是重新排列传统组织结构图中的区块，但在架构的背景下而不是孤立地思考团队，对团队和产品做出正确的决定会有很大帮助。