本书共13章，第1章引入了微服务架构模式语言的概述；第2章解释了为什么软件架构很重要，并描述了可用于将应用程序分解为服务的模式；第3章介绍了微服务架构中强大的进程间通信的几种模式；第4章介绍Saga模式；第5章介绍领域驱动设计（DDD）的聚合和领域事件等模式的使用；第6章介绍如何使用事件溯源模式；第7章介绍如何使用 API 组合模式或命令查询责任隔离（CQRS）模式；第8章介绍外部 API 模式；第9章和第10章介绍微服务自动化测试技术；第11章介绍开发生产就绪服务的各个方面；第12章介绍部署模式；第13章介绍绞杀者模式。
涵盖44个架构设计模式，系统解决服务拆分、事务管理、查询和跨服务通信等难题
易宝支付CTO陈斌、PolarisTech 联合创始人蔡书、才云科技CEO张鑫等多位专家鼎力推荐
我最喜欢的格言之一是：
未来已经到来，只是还没有平均分布。
—威廉·吉布森，科幻小说作家
这句话的实质是在说，新的想法和技术需要一段时间才能通过社区传播开来并被广泛采用。我发现并深入关注微服务的故事，就是新思想缓慢扩散的一个极好例子。这个故事始于 2006 年，当时受到 AWS 布道师一次演讲的启发，我开始走上了一条最终导致我创建早期 Cloud Foundry 的道路，它与今天的 Cloud Foundry 唯一相同的是名称。Cloud Foundry 采用平台即服务（PaaS）模式，用于在 EC2 上自动部署 Java 应用程序。与我构建的其他每个企业级 Java 应用程序一样，我的 Cloud Foundry 采用了单体架构，它由单个 Java Web 应用程序（WAR）文件构成。
将初始化、配置、监控和管理等各种复杂的功能捆绑到一个单体架构中，这给开发和运维都带来了挑战。例如，你无法在不测试和重新部署整个应用程序的情况下更改它的用户界面。因为监控和管理组件依赖于维护内存状态的复杂事件处理（CEP）引擎，所以我们无法运行应用程序的多个实例！这是个令人尴尬的事实，但我可以说的是，我是一名软件开发人员，就让我这个无辜的码农来指出这些问题吧。
显然，单体架构无法满足应用程序的需求，但替代方案是什么？在eBay 和亚马逊等公司，软件界已经开始逐渐尝试一些新东西。例如，亚马逊在 2002 年左右开始逐步从单体架构迁移（https://plus.google.com/110981030061712822816/posts/AaygmbzVeRq）。新架构用一系列松散耦合的服务取代了单体。服务由亚马逊称为“两个比萨”的团队所维护：团队规模小到两个比萨饼就能让所有人吃饱。
亚马逊采用这种架构来加快软件开发速度，以便公司能够更快地进行创新并赢得竞争。结果令人印象深刻：据报道，亚马逊平均每11.6秒就能够将代码的更改部署到生产环境中！
2010年年初，当我转向其他项目之后，我终于领悟了软件架构的未来。那时我正在读Michael T. Fisher和Martin L. Abbott 撰写的《The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise》（Addison-Wesley Professional，2009）。该书中的一个关键思想是扩展立方体，如第2章所述，它是一个用于扩展应用程序的三维模型。由扩展立方体定义的 Y 轴扩展功能将应用程序功能分解为服务。事后来看，这是显而易见的，但对我来说，这是一个让我醍醐灌顶的时刻！如果将 Cloud Foundry 设计为一组服务，我本可以解决两年前面临的挑战！
2012年4月，我首次就这种架构方法发表了题为“Decomposing Applications for Scalability and Deployability”的演讲（www.slideshare.net/chris.e.richardson/decomposing-applications-for-scalability-and-deployability-april-2012）。当时，这种架构并没有一个被普遍接受的名称。我有时称它为模块化多语言架构，因为服务可以用不同的语言编写。
未来还没有平均分布的另一个佐证是，微服务这个词在 2011 年的软件架构研讨会上被用来描述这种架构（https://en.wikipedia.org/wiki/Microservices）。当我听到 Fred George 在 Oredev 2013 上发表演讲时，我第一次遇到这个词，我立刻喜欢上了它！
2014年1月，我创建了https://microservices.io 网站，以记录我遇到的与微服务有关的架构和设计模式。在 2014 年 3 月，James Lewis 和 Martin Fowler 发表了一篇关于微服务的博客文章（https://martinfowler.com/articles/microservices.html）。随着微服务这个术语被广泛传播，这篇博客文章使整个软件社区开始围绕微服务这个新概念展开更进一步的思考和行动。
小型、松散耦合的团队快速可靠地开发和运维微服务的思想正在通过软件社区慢慢扩散。但是，这种对未来的看法可能与日常现实截然不同。如今，业务关键型企业应用程序通常是由大型团队开发的大型单体应用。虽然软件版本不经常更新，但每次更新都会给所涉及的参与人员带来巨大的痛苦。IT经常难以跟上业务需求。大家都很想知道如何采用微服务架构来解决所有这些问题。
本书的目标就是回答这个问题。它将使读者对微服务架构、它的好处和弊端，以及应该何时使用微服务架构有一个很好的理解。书中描述了如何解决我们将面临的众多架构设计挑战，包括如何管理分布式数据，还介绍了如何将单体应用程序重构为微服务架构。但本书并不是鼓吹微服务架构的宣言。相反，它的内容围绕着一系列模式进行展开。模式是在特定上下文中发生的问题的可重用解决方案。模式的优点在于，除了描述解决方案的好处之外，还描述了成功实施解决方案时必须克服的弊端和问题。根据我的经验，在选择解决方案时，这种客观性会带来更好的决策。我希望你会喜欢阅读这本书，它会教你如何成功开发基于微服务架构的应用程序。
致谢
写作是一项孤独的活动，但是把粗略的草稿变成一本完整的图书，却需要来自各方的共同努力。
首先，我要感谢 Manning 出版社的 Erin Twohey 和 Michael Stevens，他们一直鼓励我在《POJOs in Action》之后再写一本书。我还要感谢我的编辑 Cynthia Kane 和 Marina Michaels。Cynthia Kane 帮助我启动了这本书，并在前几章与我合作。Marina Michaels 接替 Cynthia 并与我一起工作到最后。Marina 对书的内容提出了细致和建设性的意见，我将永远感激不尽。我还要感谢 Manning 出版社参与了这本书的出版的其他成员。
我要感谢技术编辑 Christian Mennerich、技术校对员 Andy Miles以及所有的外部审校员：Andy Kirsch、Antonio Pessolano、Areg Melik-Adamyan、Cage Slagel、Carlos Curotto、Dror Helper、Eros Pedrini、Hugo Cruz、Irina Romanenko、Jesse Rosalia、Joe Justesen、John Guthrie、Keerthi Shetty、Michele Mauro、Paul Grebenc、Pethuru Raj、Potito Coluccelli、Shobha Iyer、Simeon Leyzerzon、Srihari Sridharan、Tim Moore、Tony Sweets、Trent Whiteley、Wes Shaddix、William E. Wheeler 和 Zoltan Hamori。
我还要感谢所有购买 MEAP 预览版并在论坛或直接向我提供反馈的人。
我要感谢我曾经参与过的所有会议和聚会的组织者及与会者，他们给了我大量的机会，让我介绍和调整我关于微服务的想法。我要感谢我在世界各地的咨询和培训客户，让我有机会帮助他们将我关于微服务的想法付诸实践。
我还要感谢 Eventuate 公司的同事 Andrew、Valentin、Artem 和 Stanislav 对 Eventuate 产品和开源项目的贡献。
最后，我要感谢妻子 Laura 和孩子Ellie、Thomas 和 Janet，感谢他们在过去的 18 个月里给予我的支持和理解。这段时间我一直盯着我的笔记本电脑，以至于接连错过了观看 Ellie 的足球比赛、Thomas 学习飞行模拟器，以及尝试与 Janet 一起开设新餐馆这些重要的家庭活动。
谢谢你们！
计算机\程序设计
全面概述了团队在转向微服务时面临的挑战，以及针对这些问题的、经过行业检验的解决方案。
—— Tim Moore，Lightbend
系统性地阐述了一个重要的架构领域。
—— Simeon Leyzerzon，Excelsior Software
一本可靠的手册，可以加快你迁移到这个基于云的现代架构的速度。
—— John Guthrie，Dell/EMC
可帮你理解微服务方法并在现实生活中使用它。
—— Potito Coluccelli，Bizmatica Econocom
喻勇翻译的这本书是近几年我所看到的众多论述微服务架构书籍中最好的一本。该书围绕微服务的架构设计，深入浅出地介绍了微服务与SOA等其他架构的区别，软件系统服务的拆分策略，微服务的同步和异步通信模式，如何使用微服务进行事务管理，如何在微服务架构中设计业务逻辑。同时详细描述了微服务架构中的测试和生产部署策略。该书所总结出的架构经验对设计微服务架构有很好的指导作用，建议软件研发人员认真研读。
—— 陈斌，易宝支付CTO
这本书里，不仅有微服务领域已经识别出来的问题、解决思路和解决方案，也有相应的代码例子。这本书可以帮助微服务相关人员构建知行合一的能力……这是一本可以帮你在设计微服务架构时做出取舍的书，它能在你处理微服务相关问题左右为难的时候给你提供参考和建议。
—— 蔡书，独立顾问，PolarisTech 联合创始人
书中既包含了微服务的原理、原则，又包含了实际落地中的架构设计模式；既包含可举一反三的理念和概念，也包含类似领域驱动设计、Saga实现事务操作、CQRS构建事件驱动系统等具体可套用的范式……相信本书对于企业CIO推动公司数字化转型战略、软件开发者提升自身技术架构功力，以及云原生爱好者以微服务切入最新的云原生体系，都有着极其重要的实践指导意义。
—— 张鑫，才云科技CEO
2012年年初，我有幸加入了VMware公司的Cloud Foundry团队，与 Chris Richardson、Patrick Chanezon、Josh Long等业界大咖共事，在全球范围内开展 Cloud Foundry 开发者社区和生态建设工作。7年前，云计算的市场格局与现在大为不同。那时，IaaS 正高歌猛进，PaaS 的价值仍旧备受质疑，“十二原则”还不为人所知，云端分布式系统的架构演化也正“摸着石头过河”。在这个时候，Chris Richardson 率先在业界提出了“Functional Decomposition”（功能性拆分）的概念，提出云计算环境下的分布式软件，应该按照功能性拆分的方式进行架构重构。这个想法与稍后业界公认的“微服务”概念不谋而合。
在VMware公司工作期间，以及之后各自的创业经历中，我跟 Chris 保持着良好的个人关系和工作合作关系。Chris是一个风趣、博学、经验丰富的架构师，他在软件行业有将近 30 年的经验，在 Java 社区更是享有盛名。在离开VMware公司后，他建立了 microservices.io
网站，专注微服务架构的咨询和培训工作，我也曾为他牵线搭桥，使他有机会为国内的企业客户提供咨询服务。
经过这些年的发展，微服务已经成为软件领域的新宠，国外Netflix、Amazon的成功案例，国内数字化转型的一波波浪潮，推动着PaaS厂商和开发者深度关注微服务。大家围绕着微服务展开了大量的讨论。在这个过程中，我们认识到，虽然很多企业客户视微服务如救命稻草，但微服务并不能解决一切问题。很多客户，亦盲从于各种厂商的“忽悠”，着力建设底层基础设施。
面对这些迷茫，Chris 曾对我说，软件的架构设计，就是选择和取舍。面对围绕微服务的众多杂音，开发者和架构师应该具备选择和取舍的能力，应该站在比较高的角度俯瞰全局、权衡利弊，做出正确的架构和技术选择。这也是最初Chris写作本书的动机之一：为架构师提供一个微服务的全局视野，并教会架构师如何在纷繁复杂的情况下做出正确的架构选择和取舍。
本书英文版的写作开始于2017年春天，2018 年 10 月正式出版。在英文版出版后，我集中利用两个多月的时间完成了中文版的翻译工作。这是一本30万字的大部头，Chris曾数次对英文版做出较大的结构性修改。为了确保中文版的一致性和准确性，并且以最快速度翻译出版，中文版初稿完成后，先后经历了7轮修改润色和校对。在后期校对阶段，我邀请了数位好友帮助把关，他们是：薛江波、王天青、季奔牛、刘果、蔡书、张鑫、张扬、黄雨婷、毛艳玲。我特别感谢这些朋友，因为他们细致地校对了所有翻译稿，帮我找到并修正了大量足以让我“晚节不保”的低级错误。蔡书和张鑫还在繁忙的创业工作之余细读整本书，并撰写了推荐序。
本书的中文版出版后，我将与 Chris 重启针对中国市场的微服务咨询和培训业务。为此，我们发布了中文网站 www.chrisrichardson.cn，并有针对性地设计了微服务培训和技术咨询的服务项目。我们期待与读者面对面交流的机会。
喻 勇
2019年2月14日
写给中文版读者的话
译者序
中文版序一
中文版序二
前言
引言
第1章 逃离单体地狱 / 1
1.1 迈向单体地狱的漫长旅程 / 2
1.1.1 FTGO应用程序的架构 / 3
1.1.2 单体架构的好处 / 4
1.1.3 什么是单体地狱 / 4
1.2 为什么本书与你有关 / 7
1.3 你会在本书中学到什么 / 8
1.4 拯救之道：微服务架构 / 8
1.4.1 扩展立方体和服务 / 9
1.4.2 微服务架构作为模块化的一种形式 / 11
1.4.3 每个服务都拥有自己的数据库 / 12
1.4.4 FTGO的微服务架构 / 12
1.4.5 微服务架构与SOA的异同 / 14
1.5 微服务架构的好处和弊端 / 15
1.5.1 微服务架构的好处 / 15
1.5.2 微服务架构的弊端 / 17
1.6 微服务架构的模式语言 / 19
1.6.1 微服务架构并不是“银弹” / 20
1.6.2 模式和模式语言 / 21
1.6.3 微服务架构的模式语言概述 / 24
1.7 微服务之上：流程和组织 / 29
1.7.1 进行软件开发和交付的组织 / 30
1.7.2 进行软件开发和交付的流程 / 31
1.7.3 采用微服务架构时的人为因素 / 32
第2章 服务的拆分策略 / 34
2.1 微服务架构到底是什么 / 35
2.1.1 软件架构是什么，为什么它如此重要 / 35
2.1.2 什么是架构的风格 / 37
2.1.3 微服务架构是一种架构风格 / 40
2.2 为应用程序定义微服务架构 / 43
2.2.1 识别系统操作 / 45
2.2.2 根据业务能力进行服务拆分 / 50
2.2.3 根据子域进行服务拆分 / 53
2.2.4 拆分的指导原则 / 54
2.2.5 拆分单体应用为服务的难点 / 56
2.2.6 定义服务API / 59
第3章 微服务架构中的进程间通信 / 63
3.1 微服务架构中的进程间通信概述 / 64
3.1.1 交互方式 / 64
3.1.2 在微服务架构中定义API / 66
3.1.3 API的演化 / 67
3.1.4 消息的格式 / 69
3.2 基于同步远程过程调用模式的通信 / 70
3.2.1 使用REST / 71
3.2.2 使用gRPC / 74
3.2.3 使用断路器模式处理局部故障 / 75
3.2.4 使用服务发现 / 78
3.3 基于异步消息模式的通信 / 82
3.3.1 什么是消息传递 / 83
3.3.2 使用消息机制实现交互方式 / 84
3.3.3 为基于消息机制的服务API创建API规范 / 86
3.3.4 使用消息代理 / 87
3.3.5 处理并发和消息顺序 / 91
3.3.6 处理重复消息 / 92
3.3.7 事务性消息 / 93
3.3.8 消息相关的类库和框架 / 97
3.4 使用异步消息提高可用性 / 99
3.4.1 同步消息会降低可用性 / 99
3.4.2 消除同步交互 / 101
第4章 使用Saga管理事务 / 106
4.1 微服务架构下的事务管理 / 107
4.1.1 微服务架构对分布式事务的需求 / 108
4.1.2 分布式事务的挑战 / 109
4.1.3 使用Saga模式维护数据一致性 / 109
4.2 Saga的协调模式 / 113
4.2.1 协同式Saga / 113
4.2.2 编排式Saga / 117
4.3 解决隔离问题 / 121
4.3.1 缺乏隔离导致的问题 / 122
4.3.2 Saga模式下实现隔离的对策 / 123
4.4 Order Service和Create Order Saga的设计 / 127
4.4.1 OrderService类 / 128
4.4.2 Create Order Saga的实现 / 129
4.4.3 OrderCommandHandlers类 / 136
4.4.4 OrderServiceConfiguration类 / 138
第5章 微服务架构中的业务逻辑设计 / 141
5.1 业务逻辑组织模式 / 142
5.1.1 使用事务脚本模式设计业务逻辑 / 143
5.1.2 使用领域模型模式设计业务逻辑 / 144
5.1.3 关于领域驱动设计 / 146
5.2 使用聚合模式设计领域模型 / 146
5.2.1 模糊边界所带来的问题 / 147
5.2.2 聚合拥有明确的边界 / 149
5.2.3 聚合的规则 / 150
5.2.4 聚合的颗粒度 / 152
5.2.5 使用聚合设计业务逻辑 / 153
5.3 发布领域事件 / 154
5.3.1 为什么需要发布变更事件 / 154
5.3.2 什么是领域事件 / 155
5.3.3 事件增强 / 155
5.3.4 识别领域事件 / 156
5.3.5 生成和发布领域事件 / 157
5.3.6 消费领域事件 / 161
5.4 Kitchen Service的业务逻辑 / 162
5.5 Order Service的业务逻辑 / 167
5.5.1 Order聚合 / 169
5.5.2 OrderService类 / 173
第6章 使用事件溯源开发业务逻辑 / 176
6.1 使用事件溯源开发业务逻辑概述 / 177
6.1.1 传统持久化技术的问题 / 177
6.1.2 什么是事件溯源 / 179
6.1.3 使用乐观锁处理并发更新 / 186
6.1.4 事件溯源和发布事件 / 186
6.1.5 使用快照提升性能 / 188
6.1.6 幂等方式的消息处理 / 189
6.1.7 领域事件的演化 / 190
6.1.8 事件溯源的好处 / 192
6.1.9 事件溯源的弊端 / 193
6.2 实现事件存储库 / 194
6.2.1 Eventuate Local事件存储库的工作原理 / 195
6.2.2 Eventuate的Java客户端框架 / 198
6.3 同时使用Saga和事件溯源 / 201
6.3.1 使用事件溯源实现协同式Saga / 203
6.3.2 创建编排式Saga / 203
6.3.3 实现基于事件溯源的Saga参与方 / 205
6.3.4 实现基于事件溯源的Saga编排器 / 208
第7章 在微服务架构中实现查询 / 212
7.1 使用API组合模式进行查询 / 213
7.1.1 findOrder()查询操作 / 213
7.1.2 什么是API组合模式 / 214
7.1.3 使用API组合模式实现findOrder()查询操作 / 215
7.1.4 API组合模式的设计缺陷 / 216
7.1.5 API组合模式的好处和弊端 / 219
7.2 使用CQRS模式 / 220
7.2.1 为什么要使用CQRS / 220
7.2.2 什么是CQRS / 223
7.2.3 CQRS的好处 / 226
7.2.4 CQRS的弊端 / 227
7.3 设计CQRS视图 / 228
7.3.1 选择视图存储库 / 229
7.3.2 设计数据访问模块 / 230
7.3.3 添加和更新CQRS视图 / 232
7.4 实现基于AWS DynamoDB的CQRS视图 / 233
7.4.1 OrderHistoryEventHandlers模块 / 234
7.4.2 DynamoDB中的数据建模和查询设计 / 235
7.4.3 OrderHistoryDaoDynamoDb类 / 239
第8章 外部API模式 / 244
8.1 外部API的设计难题 / 245
8.1.1 FTGO移动客户端API的设计难题 / 246
8.1.2 其他类型客户端API的设计难题 / 248
8.2 API Gateway模式 / 250
8.2.1 什么是API Gateway模式 / 250
8.2.2 API Gateway模式的好处和弊端 / 256
8.2.3 以Netflix为例的API Gateway / 257
8.2.4 API Gateway的设计难题 / 258
8.3 实现一个API Gateway / 260
8.3.1 使用现成的API Gateway产品或服务 / 261
8.3.2 开发自己的API Gateway / 262
8.3.3 使用GraphQL实现API Gateway / 269
第9章 微服务架构中的测试策略（上） / 282
9.1 微服务架构中的测试策略概述 / 284
9.1.1 什么是测试 / 284
9.1.2 微服务架构中的测试挑战 / 289
9.1.3 部署流水线 / 295
9.2 为服务编写单元测试 / 296
9.2.1 为实体编写单元测试 / 298
9.2.2 为值对象编写单元测试 / 299
9.2.3 为Saga编写单元测试 / 300
9.2.4 为领域服务编写单元测试 / 302
9.2.5 为控制器编写单元测试 / 303
9.2.6 为事件和消息处理程序编写单元测试 / 305
第10章 微服务架构中的测试策略（下） / 308
10.1 编写集成测试 / 308
10.1.1 针对持久化层的集成测试 / 311
10.1.2 针对基于REST的请求/响应式交互的集成测试 / 312
10.1.3 针对发布/订阅式交互的集成测试 / 316
10.1.4 针对异步请求/响应式交互的集成契约测试 / 320
10.2 编写组件测试 / 324
10.2.1 定义验收测试 / 325
10.2.2 使用Gherkin编写验收测试 / 326
10.2.3 设计组件测试 / 328
10.2.4 为FTGO的Order Service编写组件测试 / 330
10.3 端到端测试 / 334
10.3.1 设计端到端测试 / 335
10.3.2 编写端到端测试 / 335
10.3.3 运行端到端测试 / 336
第11章 开发面向生产环境的微服务应用 / 338
11.1 开发安全的服务 / 339
11.1.1 传统单体应用程序的安全性 / 340
11.1.2 在微服务架构中实现安全性 / 343
11.2 设计可配置的服务 / 349
11.2.1 使用基于推送的外部化配置 / 350
11.2.2 使用基于拉取的外部化配置 / 352
11.3 设计可观测的服务 / 353
11.3.1 使用健康检查API模式 / 355
11.3.2 使用日志聚合模式 / 357
11.3.3 使用分布式追踪模式 / 358
11.3.4 使用应用程序指标模式 / 361
11.3.5 使用异常追踪模式 / 364
11.3.6 使用审计日志模式 / 365
11.4 使用微服务基底模式开发服务 / 367
11.4.1 使用微服务基底 / 368
11.4.2 从微服务基底到服务网格 / 368
第12章 部署微服务应用 / 371
12.1 部署模式：编程语言特定的发布包格式 / 374
12.1.1 使用编程语言特定的发布包格式进行部署的好处 / 376
12.1.2 使用编程语言特定的发布包格式进行部署的弊端 / 377
12.2 部署模式：将服务部署为虚拟机 / 378
12.2.1 将服务部署为虚拟机的好处 / 380
12.2.2 将服务部署为虚拟机的弊端 / 380
12.3 部署模式：将服务部署为容器 / 381
12.3.1 使用Docker部署服务 / 383
12.3.2 将服务部署为容器的好处 / 385
12.3.3 将服务部署为容器的弊端 / 386
12.4 使用Kubernetes部署FTGO应用程序 / 386
12.4.1 什么是Kubernetes / 386
12.4.2 在Kubernetes上部署Restaurant Service / 389
12.4.3 部署API Gateway / 392
12.4.4 零停机部署 / 393
12.4.5 使用服务网格分隔部署与发布流程 / 394
12.5 部署模式：Serverless部署 / 402
12.5.1 使用AWS Lambda进行Serverless部署 / 403
12.5.2 开发Lambda函数 / 404
12.5.3 调用Lambda函数 / 404
12.5.4 使用Lambda函数的好处 / 405
12.5.5 使用Lambda函数的弊端 / 406
12.6 使用AWS Lambda和AWS Gateway部署RESTful服务 / 406
12.6.1 AWS Lambda版本的Restaurant Service / 407
12.6.2 把服务打包为ZIP文件 / 411
12.6.3 使用Serverless框架部署Lambda函数 / 412
第13章 微服务架构的重构策略 / 415
13.1 重构到微服务需要考虑的问题 / 416
13.1.1 为什么要重构单体应用 / 416
13.1.2 绞杀单体应用 / 417
13.2 将单体应用重构为微服务架构的若干策略 / 420
13.2.1 将新功能实现为服务 / 420
13.2.2 隔离表现层与后端 / 422
13.2.3 提取业务能力到服务中 / 423
13.3 设计服务与单体的协作方式 / 429
13.3.1 设计集成胶水 / 430
13.3.2 在服务和单体之间维持数据一致性 / 434
13.3.3 处理身份验证和访问授权 / 438
13.4 将新功能实现为服务：处理错误配送订单 / 440
13.4.1 Delayed Delivery Service的设计 / 441
13.4.2 为Delayed Delivery Service设计集成胶水 / 442
13.5 从单体中提取送餐管理功能 / 444
13.5.1 现有的送餐管理功能 / 444
13.5.2 Delivery Service概览 / 446
13.5.3 设计Delivery Service的领域模型 / 447
13.5.4 Delivery Service集成胶水的设计 / 450
13.5.5 修改FTGO单体使其能够与Delivery Service交互 / 451
