（本文是对《 Building Microservices》一书第10章的摘录）
Melvin Conway于1968年发表的论文《 How Do Committees Invent》指出：系统设计的结构必定复制设计该系统的组织的沟通结构。这一论断被称为“康威定律”。在《 Exploring the Duality Between Product and Organizational Architectures》一文中，作者发现紧密耦合的组织（例如典型的商业产品公司，所有员工在同一地点工作，具有高度一致的愿景与目标）开发的软件倾向于较少模块化，而松散耦合的组织（例如分布式的开源社区）开发的软件则倾向于更加模块化、耦合较少。
当一支小型团队负责整个系统的设计与实现时，团队内部可以具有频繁的、细粒度的沟通。而随着团队变大、分布在不同地点甚至时区，协调变更成本急剧增加，紧跟着就有两种可能性：人们要么找到降低协作／沟通成本的办法，或是停止做变更。后者就会导致庞大、难以维护的代码库。最终，各个地点不得不选择各自专门处理的一部分工作，拥有一部分代码，并在团队之间形成更粗粒度的沟通机制。组织结构中的沟通路径会造就与之对应的粗粒度API，形成代码库各个大块之间的边界。
服务的边界应该围绕着约束上下文（ bounded context）来画，正如我们希望团队结构与约束上下文保持一致。这样做有几方面的好处。首先，团队在一个约束上下文内更容易抓住领域概念；其次，一个约束上下文内的多个服务更可能彼此交互，因此系统设计和发布协作都得以简化；最后，交付团队与业务代表沟通时，团队只需与各自约束上下文中的一两个专家建立良好关系即可。
一般而言，每个服务属于一个团队，拥有这个服务的团队负责其所有修改。这个团队可以任意调整代码结构，只要这些修改不对服务的消费者造成破坏即可。在很多团队中，“所有权”延伸到了服务的各个方面，从需求来源直到软件的构建、部署和维护。由同一个团队负责开发、部署和维护会促使他们简化部署环节，而不是“写完代码扔过墙”。
有很多团队采用“共享服务所有权”的模式。这种模式并不理想，但有必要了解团队为什么做此选择。常见的理由包括：
通常的开源项目组织方式可以用在企业内部：一个代码库由一组受信任的提交者（核心团队）管理，并接受未获信任的提交者（外围团队）提交的修改。开源项目以这种方式来保障代码质量和一致性。大多数开源项目在第一个核心版本成型之前倾向于不接受外来的提交。当服务变得成熟且稳定，便可以更放心地开放接受贡献。
分布式版本控制工具允许任何人提交pull request，这是很重要的能力。取决于组织的规模，内部开源体系可能需要考虑借助代码评审工具来讨论和评估是否接受pull request。同时，类似于github提供的pull request评论功能也很有用。最后，需要让提交者很容易构建和部署整个软件，通常这需要定义良好的构建和部署流水线，以及集中管理的构建产物仓库。
REA的服务由“小队”（squad）拥有，小队负责服务的整个生命周期，包括构建、测试、发布、支持、直到下线。一支交付服务团队给这些小队提供建议和指导，以及必要的工具支持。REA有着强烈的自动化文化，并大量使用AWS使团队更具自主性。
不仅交付团队与业务经营对齐，软件架构也是一样。以服务集成为例：在一条业务线内部，所有服务可以用任何方式自由交流，小队自己可以做决定；然而在业务线之间，所有交流必须以异步批处理的形式发生，这是中央架构团队规定的很少几条“铁律”之一。粗粒度的系统集成与业务线之间已有的粗粒度交流相匹配。
为了对齐业务经营，组织结构和软件架构都需要改变。变革的阻力真实存在：从大一统的系统转到微服务，对于习惯了单一编程语言、不用考虑运维问题的开发者而言是一次痛苦的觉醒；习惯了把软件“丢过墙”的程序员突然发现没有别人可以推诿责任，可能会很不习惯自己对所有工作负责；如果要让开发者承担7*24在线支持工作，甚至可能有劳动合同上的阻碍。变革推动者需要理解员工的喜恶，顺势而为，不能急于求成。