康威定律

      任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

——梅尔.康威

      如何理解这句话在软件工程上的含义？埃里克.S.雷蒙德说：如果你有四个小组开发一个编译器，那你会得到一个四步编译器。

      组织和架构应该一致，团队应该共同拥有并运营其创建的系统，而且小团队会比大团队的工作更有效。Amazon提出“两个披萨团队”，即没有一个团队应该大到两个披萨不够吃，帮助小团队对服务的整个生命周期负责，这也是现如今Devops如此流行的一个原因。

      组织结构对系统的性质和质量有着深刻的影响，如果构建系统的组织更加松耦合，其所构建的系统则倾向于更加模块化，因此耦合度也更低。我们推荐团队与限办上下文保持一致，同时确保每个服务都有拥有者，这样当这个服务几个月没有改时，再修改也会找到相应的团队。

      我们倾向于把服务的所有权交给拥有服务的团队，只要更改不破坏服务的消费者，团队就可以随时重新组织代码，这样可以让团队更加负责，而不是反映系统移交到测试或部署阶段后，就认为他们的工作已经完成了。

      另外，系统的设计有时也会反过来失去组织的发展，如以前互联网仅是一个附加在信息部门的小部门，而现如今，互联网可能带来整个公司组织架构的调整。我们称之为反向的康威定律。

 

内部开源

      如果团队内最终免不了要共享几个服务时，该怎么办？内部开源可能是一个选项。

      在标准的开源项目中，一小部分人被认为是核心提交者，他们是代码的守护者，核心提交者对代码库负责，他们是代码库的所有者。

      好的守护者会花费大量的精力与提交者进行清晰的沟通，并对他们的工作方式进行引导。

      在内部开源项目开始时，由于其可能处于快速的变化当中，这个时候最好不要允许除了核心提交者之外的人提交代码。待成熟之后，再来开放，让其他人贡献代码。

 

参考

      《微服务设计》（Sam Newman 著 / 崔力强 张骏 译）

相关文章： 

• 微服务的概念——《微服务设计》读书笔记

• 微服务架构师的职责——《微服务设计读书笔记》

• 建模:确定服务的边界——《微服务设计》读书笔记

• 微服务集成——《微服务设计》读书笔记

• 服务的协作：服务间的消息传递——《微服务设计》读书笔记

• 拆分:分解单块系统——《微服务设计》读书笔记

• 部署:持续集成（CI）与持续交付（CD）——《微服务设计》读书笔记

• 测试——《微服务设计》读书笔记

• 监控——《微服务设计》读书笔记

• 安全——《微服务设计》读书笔记

原文地址：http://www.cnblogs.com/gudi/p/6685038.html

---

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注