康威定律和系统设计——《微服务设计》读书笔记

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

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

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

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

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

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

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

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

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

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

原文地址：http://www.cnblogs.com/gudi/p/6685038.html
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注