《微服务设计》，Building Microservices，作者Sam Newman，译者崔力强、张骏，人民邮电出版社，2016年。

笔记中有些内容直接引用原书。

================================================================

第十章康威定律和系统设计

梅尔·康威于1968年4月在Datamation杂志上发表的“How Do Committees Invent”文章指出：任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

1.证据

松耦合组织和紧耦合组织。紧耦合组织的代表是商业产品公司，松耦合的代表是分布式开源社区。研究发现组织耦合度越低，其创建的系统的模块化约好，耦合也越低。反之亦然。

Windows Vista。对该产品的研究表明：与组织结构相关联的指标和软件质量的相关度最高。

2.Netflix和Amazon

二者都是崇尚小团队开发。

3.我们可以做什么

看看不同组织的情况。

4.适应沟通途径

5.服务所有权

服务所有权：拥有服务的团队负责对该服务进行更改。延伸开来包括需求、构建、部署和运维。

6.共享服务的原因

共享服务所有权效果不佳，采用共享服务的原因如下。

难以分割。拆分成本高。可参考第五章的建议。

特性团队。基于特性开发的团队。例如一个团队专门负责用户界面，另一个负责应用逻辑，另一个负责处理数据库。这还是服务共享，会出现大量问题。服务应根据业务建模，而不是根据技术。

交付瓶颈。共享服务，可以避免交付瓶颈。因为人员可以共享。但可以使用下面的方式避免采用共享服务。

7.内部开源

核心提交者是代码的守护者和代码库的所有者，其他人要修改代码，向他们提交pull，核心提交者来审核。

守护者的角色。好的守护者会花大量精力与提交者进行清晰的沟通。

成熟。代码成熟后再允许外部提交者贡献代码。

工具。支持pull的分布式版本控制工具，支持讨论和修改提交申请的工具等。

8.限界上下文和团队结构

根据限界上下文确定服务边界，与团队结构保持一致。

9.孤儿服务

不再活跃维护的服务仍然有其所有并负责的团队。

10.案例研究：RealEstate.com.au

每条业务线有其团队，负责自己创造的服务的整个生命周期。一个核心服务交付团队，为这些团队提供建议、指导和工具。一个业务线内的服务可以不受限制的通信，业务线之间的服务通信必须是异步批处理。

11.反向的康威定律。

无论系统有什么设计缺陷，都不得不通过改变组织结构来推动系统的更改。

12.人

从单块系统开发人员过渡到微服务系统开发人员需要时间来适应和改变，给他们时间，告诉他们的职责。

13.小结

要尽量使得系统设计与组织结构相匹配。