康威定律：
让你和组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都于该组织的沟通结构保持一致。
10.1 证据
据说，当年康威将这个话题的论文提交给《哈佛商业评论》时被拒绝了，因为他们认为没有证据能够证明他的论点。但越来越多的人同意这个观点，因为这个观点在不断的在实际场景中得到证实。
10.1.1 松耦合组织和紧耦合组织
松耦合组织：典型的一个例子是商业产品公司，他们的员工在引起工作，并有着一致的愿景和目标
紧耦合组织：典型的代表是分布式开源社区
组织的耦合度月底，其创建的系统的模块化就越好
10.1.2 WindowsVista
微软度它的一个特定产品Windows Vista进行了实例研究（http://research.microsoft.com/pubs/70535/tr-2008-11.pdf）,观察其自身组织结构如何影响软件质量。具体而言，研究者通过查看多种因素来确定系统中什么样的组件容易出错。
（微软已被各种黑出x...）
10.2 Netflix和Amazon
组件和架构应该一致，信奉这个理念的两个典范是Amazon和Netfilx。Amazon也相信，小团队比大团队的工作更有效，于是产生了著名的“两个披萨团队”，即没有要给团队应该大到两个披萨不够吃。帮助小团队对服务的整个生命周期负责，是驱动Amazon开发AWS的一个主要原因，团队需要一些工具来自助式地获取相应的计算资源。
Netflix为了想要的系统架构，从一开始，它就确保其本身是由多个小而独立的团队组成，以保证他们创建的服务也能独立于彼此。
10.3 我们可以做什么
各种证据和经验都表明，组织结构对系统的性质和质量确实有着深刻的影响。
10.4 适应沟通途径
当构建一个服务的团队不再是一个单一的，物理位置上在一起的团队。异地分布式团队的沟通成本比较高，因此协调变化的成本也比较高。（设想一个场景，前后端分离后，在夏威夷的团队负责前端，在巴西的团队负责后端，变更和新需求到来时，沟通的成本和难度可想而知）
当协调变化的成本增加后，由一件事情会发生：人们要门想法设法降低协调/沟通成本，要么停止更改。而后者正是导致我们最终产生庞大的，难以维护的代码库的原因。
作者认为，参与创建系统的开发人员之间存在地里位置差异，是一个应该对服务进行分解的很明显的信号，一般来说，你应该分配单个服务的所有全给可以保持低成本变化的团队。（书本中的知识和实际情况）
如果构建系统的组织更加松耦合，其所构建的系统则倾向于更加模块化，因此耦合度也越低。一个拥有许多服务的单个团队对其管理的服务会倾向于更紧密的集成，而这种方式在分布式组织中是很难维护的。
10.5 服务所有权
一般来说，拥有服务的团队负责对该服务进行更改。只要更改不破坏服务的消费者，团队就可以随时重新组织代码。从应用程序的需求，构建，部署到运维 ，团队需要自己负责部署和维护应用程序，这会激励团队创建出易于部署的服务。
个人感悟：当你是最后一棒的时候，你就不会想着再依赖别人。当没有人能够接受你扔出去的东西时，也就不用担心人们会犯“把东西扔出墙”这种错误了。
10.6 共享服务的原因
理解人们为何选用共享服务的原因是很重要的，尤其是当我们能够找到一些令人信服的替代模式。
10.6.1 难以分割
拆分服务成本太高，难以分割，是多个团队负责单个服务的原因之一。
10.6.2 特性团队
你的组织中可能有一个图团队专门负责用户界面，另一个团队负责应用程序逻辑，第三个团队负责处理数据库。
我们要尽量避免技术导向的团队，这样出现特性团队的可能性就会降低，更容易形成自治，独立的微服务团队（度的把握）
10.6.3 交付瓶颈
共享服务的另一个关键原因是，这样做可以避免交付瓶颈。如果某个服务突然出现大量的变更需求，但不幸的是，团队的一般成员感染了流感，而另一半被困在了生产环境上的故障诊断中。
如果不共享服务，有几种办法：
1.等待，可以先去开发其他的功能，等待这一块儿功能完成后再回头做这一块的功能。
2.派人到其他团队帮助他们更快的工作。
3.帮对应的服务分拆的更小，共享部分服务。
不过，还有更好的办法。
10.7 内部开源
如果已经尽力，但还是没有好的办法来避免共享几个服务该怎么办？这个时候，拥抱内部开源模式可能更合理（mdf2.0）,尤其是对于公用类型的组件和服务，内部开源是不错的选择。
10.7.1 守护者的角色
内部也要采用跟标准开源项目同样的模式。这需要分理处一组受新人的提交者（核心团队）和不受新人的提交者（团队外提交变更的人）
核心团队需要对更改有某种程度的审批。它需要确保所有的更改符合该代码库的惯例。做审批的人不得不花时间再提交者身上，以确保得到高质量的更改。
10.7.2 成熟
服务越不稳定或越不程数，就越难让核心团队之外的人提交更改。大多数开源项目再完成第一个版本的核心代码前，往往不允许让更广泛的不受新人的提交者们提交代码。如果一个服务已经相当程数，而且很少改变，那么这时，才是开源并让其他人贡献代码的最好时机。
10.7.3 工具
git就不错。
10.8 限界上下文和团队结构
我们以限界上下文来定义服务的边界。我们希望团队也与限界上下文保持一致。
1.团队会发现它的限界上下文内更容易掌握领域的概念，因为它们是相关联的。
2.限界上下文有可能发生交互，保持一致可以简化系统设计和发布的协调工作。
3.再交付团队与业务干系人进行交互方面，它有利于团队与此领域内的一两个专家创建良好的合作关系
10.9 孤儿服务
如何处理不再活跃维护的服务呢？如果你的团队结构于组织的衔接上下文是一致的，那么即使是修改频率很低的服务也回有实际的所有者。另外，如果你的服务采用了多语言方案，使用了多个技术栈，那么当你的团队不了解故而服务的技术栈时，更改它的挑战可能会加大。
10.10 案例研究
10.11 反向的康威定律
系统设计能够反过来影响组织的结构。
10.12 人（管理者该有的意识）
不管一开始看起来什么样，它永远是人的问题。
再微服务环境中，开发人员很难旨在自己的小世界中编写代码。他需要意识到像跨网络边界调用及隐式失败等问题。如果你从一个单块系统的世界走来，那里大多数开发人员只需要使用一种语言，并且对运维完全没有意识，那么直接把他们扔到微服务的世界，就像是粗鲁地把他们从单纯的世界中叫醒一样。
赋权给开发团队以增加自治也是充满挑战的。过去的习惯是把工作扔个别人，习惯指责别人，现在让他们对自己的工作完全负责可能会让人感觉不舒服（不习惯，心里不平衡，这很正常，但自己的心想去哪里只有自己知道）。曾经的六日是休闲，现在恐怖的公司可能要求你7*24小时待命，心态的变化可想而知。
人的问题绝不只是一个次要的问题，不考虑当前员工的感受，或不考虑他们现有的能力来提出一个该如何做事的设想，有可能导致一个糟糕的结果。
每个组织都有自己的节奏，了解你的员工能够承受的变化，不要逼他们改变太快。对许多人来说，这将是一个非常可怕的旅程，尤其是要经过“断崖式学习”的过程。如果没有把人们拉到一条船上，你想要的任何变化从一开始就注定会失败。
网友评论