有利于团队协作流程的软件架构

康威定律告诉我们，在设计组织团队之前，首先要弄明白我们所希望的软件架构是怎样的，否则组织中的沟通路径和激励将最终决定软件架构。正如Michael Nygard所说的那样：“团队划分是软件架构的第1版草稿。”

为了实现安全、快速的变更流程，我们需要考虑便于团队协作的流程并设计与之匹配的软件架构。交付的基础是团队（详见第3章），因此系统架构需要鼓励每个团队间的快速流动。值得庆幸的是，在具体实践中，这意味着我们需要遵循那些经过验证的软件架构的良好实践。

· 松耦合：组件不强依赖于其他组件。

· 高内聚：组件拥有清晰的职责边界，并且它们的内部元素强相关。

· 清晰合理的版本兼容性。

· 清晰合理的跨团队测试。

从理论上讲，软件架构应该同它所实现的变更流程类似，而并非仅仅是一系列相互关联的组件，我们应该在一个底层平台上设计工作流（这部分内容在第5章有详细介绍）。

通过控制团队规模，我们得以达成MacCormack和他同事提出的“如果想要一个架构易于理解，那么就应该控制模块大小，并尽可能地减少设计变更的波及范围，从而让架构对于贡献者（Contribution）更加友好”。换句话说，我们需要通过团队优先的软件架构来最大化人的能力和产出。

保持解耦和团队内部协作应该是一个对组织核心、长期存在的考验，因为正如John Roberts在《现代企业》（The Modern Firm）中所说的那样，“采用一种遵循离散模型的设计，往往可以在效能方面获得实质收益。”这些效能收益一部分来自变更流程获得的提升，另一部分得益于组织为了适应环境而改变架构的能力。

The Principles of Product Development Flow的作者Don Reinertsen说道：“我们也可以将架构开发成快速变更的使能者。我们通过架构分区来优雅地吸纳变更。”因此，我们只有遵循了康威定律提出的团队优先方法，架构才能成为赋能者而非绊脚石。