组织：康威定律和系统设计

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

1. 证据

1) 松耦合组织和紧耦合组织

紧耦合组织的一个例子时商业产品公司，员工在一起工作，并有着一致的愿景和目标

松耦合组织的典型代表时发布时开源社区。

研究发现（Exploring the Duality Between Product. And Organizational Architectures, 作者：Alan MacCormack、John Rusnak和Carliss Baldwin）：组织的耦合性越低，其创建的系统的模块化越好，耦合也越低；组织的耦合度越高，其创建的系统的模块化也越差。

2. Amazon和Netflix

信奉组织和架构保持一致的两个典范是Amazon和Netflix

1) Amazon：

a. 团队对服务／所管理系统的整个生命周期负责

b. 两个比萨团队：小团队比大团队的工作更有效。

2) Netflix：

a. 确保其本身由多个小而独立的团队组成，以保证创建的服务能独立于彼此

3. 我们可以做的：

3.1 适应沟通途径，划分服务所有权

1) 适应沟通途径：

a. 参与创建系统的开发人员中间存在地理位置差异，是一个应该对服务进行分解的很明显的信号。

b. 一般来说，应该分配单个服务的所有权给可以保持低成本变化的团队

c. 积极思考系统的那部分可以移交给异地办公的新团队：按照接缝拆分

d. 一个团队对其管理的服务会倾向于更紧密地集成，而这种方式在分布式组织中是很难维护的

2) 服务所有权

a. 所有权延伸到服务的方方面面，从应用程序的需求、构建、部署到运维

b. 所有权程度的增加会提高自治和交付速度

c. 团队需要自己负责部署和维护应用程序，这会激励团队创建出易于部署的服务（所谓的自吃狗粮？）

3.2 分析共享服务的原因，找出令人信服的替代方式

共享服务的效果不佳

1）共享服务的原因：

a. 难以分割：拆分服务的成本太高，常见于大型的单块系统中

b. 特性团队：基于特性开发的团队。一个小团队负责开发一系列特性需要的所有功能，即使这些功能需要跨越组件（甚至服务）的边界。

例如：跨越用户界面、用户逻辑及数据库，提供完整的功能

大范围采用特性团队后，所有服务都是共享的。

如果负责某个微服务的团队与业务领域相匹配，它更容易保持对客户的关注，也更容易进行以特性为导向的开发。

c. 交付瓶颈：避免交付瓶颈是共享服务的另一个关键原因。

2) 替代方案：内部开源

a. 守护者：在内部需要分离出一组受信任的提交者（核心团队）和不受信任的提交者（团队外提交变更的人）

核心团队需要对更改由某种程度的审批，确保所有的更改服务该代码库的惯例，遵循和代码库其它代码一致的编码准则

b. 成熟

服务越不稳定或越不成熟，就越难让核心团队之外的人提交更改。

如果一个服务已经相当成熟，而且很少改变，才是开源并让其他人贡献代码的最好时机

（如何判定一个服务是成熟的？）

c. 工具

使用支持pull请求的分布式版本控制工具；

支持讨论和修改提交申请的工具

良好的构建和部署流水线，以及集中构件物仓库

4. 限界上下文和交付团队结构

保持交付团队和限界上下文一致的好处：

1) 团队会更容易掌握领域的概念，因为它们是相互关联的

2) 限界上下文的服务更可能发生交互，保持一致可以简化系统设计和发布的协调工作

3) 在交付团队和业务干系人进行交互方面，有利于团队与此领域内的一两个专家创建良好的合作关系

5. 孤儿服务

1) 什么是孤儿服务？

不再活跃或修改频率很低的服务

2) 如何处理孤儿服务？

如果团队结构和组织的限界上下文是一致的，即使是孤儿服务也会有实际的所有者。

6. 案例研究

1) 每条业务线交付团队，负责自己创建的服务的整个生命周期，包括构建、测试、发布和运维，甚至弃用

2) 一个核心交付服务团队，为业务线交付团队提供建议、指导和工具来帮助他们完成工作。

3) 浓厚的自动化文化

4) 与业务相一致的架构。

例如集成方式：

a. 一条业务线内，服务间可以不受任何限制地以任何方式来通信，只要团队确定的服务守护者认为合适

b. 业务线之间，所有的通信都必须是异步批处理。

7. 反向的康威定律：系统架构设计对组织的反向作用

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

8. 人

“不管一开始看起来什么样，它永远是人的问题“

 -- 温伯格（没听说过），咨询第二定律

每个组织都有自己的节奏，了解员工能够承受的变化，不要逼他们改变太快。

需要跟员工清楚的阐述，在微服务的世界里每个人的责任，以及为何这些责任如此重要。