系列文章目录：
康威定律
任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
——梅尔.康威
如何理解这句话在软件工程上的含义？埃里克.S.雷蒙德说：如果你有四个小组开发一个编译器，那你会得到一个四步编译器。
组织和架构应该一致，团队应该共同拥有并运营其创建的系统，而且小团队会比大团队的工作更有效。Amazon提出“两个披萨团队”，即没有一个团队应该大到两个披萨不够吃，帮助小团队对服务的整个生命周期负责，这也是现如今Devops如此流行的一个原因。
组织结构对系统的性质和质量有着深刻的影响，如果构建系统的组织更加松耦合，其所构建的系统则倾向于更加模块化，因此耦合度也更低。我们推荐团队与限办上下文保持一致，同时确保每个服务都有拥有者，这样当这个服务几个月没有改时，再修改也会找到相应的团队。
我们倾向于把服务的所有权交给拥有服务的团队，只要更改不破坏服务的消费者，团队就可以随时重新组织代码，这样可以让团队更加负责，而不是反映系统移交到测试或部署阶段后，就认为他们的工作已经完成了。
另外，系统的设计有时也会反过来失去组织的发展，如以前互联网仅是一个附加在信息部门的小部门，而现如今，互联网可能带来整个公司组织架构的调整。我们称之为反向的康威定律。
内部开源
如果团队内最终免不了要共享几个服务时，该怎么办？内部开源可能是一个选项。
在标准的开源项目中，一小部分人被认为是核心提交者，他们是代码的守护者，核心提交者对代码库负责，他们是代码库的所有者。
好的守护者会花费大量的精力与提交者进行清晰的沟通，并对他们的工作方式进行引导。
在内部开源项目开始时，由于其可能处于快速的变化当中，这个时候最好不要允许除了核心提交者之外的人提交代码。待成熟之后，再来开放，让其他人贡献代码。
参考
《微服务设计》（Sam Newman 著 / 崔力强 张骏 译）