《CTO必读套装中台微服务DDD全面落地（套装共2册）》 - [美]克里斯·理查森[Chris Richardson]著， - 机械工业出版社 - 香港大書城

	登入帳戶　 \|　訂單查詢　 \|　購物車/收銀台(0)　\|　在線留言板　 \|　付款方式　 \|　運費計算　 \|　聯絡我們　 \|　幫助中心　\|　加入書簽
		會員登入新用戶登記

HOME

新書上架

暢銷書架

好書推介

2024年度TOP

臺灣用戶

品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心

服務：香港／台灣／澳門／海外

送貨：速遞／郵局／服務站

新書上架：簡體書繁體書
暢銷書架：簡體書繁體書
好書推介：簡體書繁體書

『簡體書』CTO必读套装中台微服务DDD全面落地（套装共2册）

書城自編碼： 3599883
分類：簡體書→大陸圖書→計算機/網絡→程序設計
作者： [美]克里斯·理查森[Chris Richardson]著，
國際書號(ISBN)： 9787X29206228
出版社：机械工业出版社
出版日期： 2021-02-01

頁數/字數： /
書度/開本： 16开釘裝：平装

售價：HK$ 285.0

我要買件

** 我創建的書架 **
未登入.

新書推薦：

《一群数学家分蛋糕：提升逻辑力的100道谜题》
售價：HK$ 60.5

《无解的困局：大明最后的60年》
售價：HK$ 66.0

《女校（人气作家孩子帮·鹅随“北番高中”系列代表作！）》
售價：HK$ 60.5

《万历十八年之风起辽东》
售價：HK$ 85.8

《实战ANSYS Icepak电子热设计》
售價：HK$ 97.9

《水库式经营》
售價：HK$ 61.6

《哲学家的最后一课》
售價：HK$ 57.8

《进入全球公共视域的清帝国：欧洲文献里的中国邸报》
售價：HK$ 139.2

建議一齊購買：

HK$ 127.7
《重构改善既有代码的设计》

HK$ 145.2
《深入理解分布式事务：原理与实战》

HK$ 68.8
《HTML5与CSS3程序设计》

HK$ 101.2
《顶点覆盖问题的求解算法研究》

HK$ 114.8
《设计模式之美》

編輯推薦：

《微服务架构设计模式》
本书由世界十大软件架构师之一、微服务架构的先驱、Java开发者社区的意见领袖Chris Richardson亲笔撰写，旨在帮助架构师和程序员学会使用微服务架构成功开发应用程序。
书中描述了如何解决我们将面临的众多架构设计挑战，包括如何管理分布式数据，还介绍了如何将单体应用程序重构为微服务架构，涵盖44个架构设计模式，系统解决服务拆分、事务管理、查询和跨服务通信等难题。
本书并不是鼓吹微服务架构的宣言，作者既介绍了微服务的原理、原则，又详细讲解了实际落地中的架构设计模式，将使你理解微服务架构、它的好处和弊端，以及应该何时使用微服务架构。本书将帮助你建立微服务的全局视野，并学会在纷繁复杂的情况下做出正确的架构选择和取舍。
本书将教会你如何开发和部署生产级别的微服务架构应用。这套宝贵的架构设计模式建立在数十年的分布式系统经验之上，Chris还为开发服务添加了新的模式，并将它们组合成可在真实条件下可靠地扩展和执行的系统。本书不仅仅是一个模式目录，还提供了经验驱动的建议，以帮助你设计、实现、测试和部署基于微服务的应用程序。
本书包含：
●如何（以及为什么）使用

內容簡介：

《微服务架构设计模式/架构师书库》：
　　成功地开发基于微服务架构的应用软件，需要掌握一系列全新的架构思想和实践。在这本独特的书籍中，微服务架构的先驱、Java开发者社区的意见领袖ChrisRichardson收集、分类并解释了44个架构设计模式，这些模式可用来解决诸如服务拆分、事务管理、查询和跨服务通信等难题。
　　《微服务架构设计模式/架构师书库》将教会你如何开发和部署生产级别的微服务架构应用。这套宝贵的架构设计模式建立在数十年的分布式系统经验之上，Chris还为开发服务添加了新的模式，并将它们组合成可在真实条件下可靠地扩展和执行的系统。
　　《微服务架构设计模式/架构师书库》不仅仅是一个模式目录，还提供了经验驱动的建议，以帮助你设计、实现、测试和部署基于微服务的应用程序。
　　《微服务架构设计模式/架构师书库》包含：
　　如何（以及为什么）使用微服务架构
　　服务拆分的策略
　　事务管理和查询相关的模式
　　高效的测试策略
　　包括容器和Serverless在内的部署模式
　　《微服务架构设计模式/架构师书库》专为熟悉标准企业应用程序架构的开发人员编写，使用Java编写所有示例代码。
　　
　　《中台架构与实现（基于DDD和微服务）》：
　　《中台架构与实现（基于DDD和微服务）》是一部系统讲解如何基于DDD思想实现中台和微服务协同设计和落地的著作。它将DDD、中台和微服务三者结合，给出了一套体系化的基于DDD思想的企业级前、中、后台协同设计方法。一方面，它为中台的划分和领域建模提供指导，帮助企业更好地完成中台建设，实现中台的能力复用；另一方面，它为微服务的拆分和设计提供指导，帮助团队提升分布式微服务的架构设计能力。
　　《中台架构与实现（基于DDD和微服务）》注重实战，汇聚了大量分布式架构的新设计方法、思想和理念，同时包含大量的案例和代码，是理论与实践相结合的好的经验分享。文字有活力，内容不刻板，简洁易懂。
　　《中台架构与实现（基于DDD和微服务）》共分为六个部分。
　　***分认识中台（第1～4章）
　　主要从业务中台、数据中台、技术中台以及与之匹配的组织架构等多个方面分析传统企业中台转型应该具备的能力，带你初步了解DDD如何指导中台和微服务设计，并厘清它们的协作关系。
　　第二部分DDD基本原理（第5～11章）
　　通过浅显易懂的案例讲解DDD的核心基础知识、设计思想、原则和方法等内容，了解它们之间的协作和依赖关系，做好中台实践前的准备工作。
　　第三部分中台领域建模与微服务设计（第12～19章）
　　首先，通过案例手把手带你用DDD方法完成中台和微服务的全流程设计，深刻理解DDD在中台领域建模与微服务设计中的步骤、方法、设计思想和价值；然后，通过一个完整案例带你了解用DDD设计方法完成领域建模与微服务设计的全流程。
　　第四部分前端设计（第20～21章）
　　引入微前端和单元化的设计思想，通过前端微服务化和单元化设计思想，解决业务中台建设完成后前端应用解耦和前后端服务集成复杂的难点。此外，还探讨了基于领域模型的单元化设计方法。
　　第五部分中台设计案例（第22章）
　　采用自顶向下的领域建模策略，通过案例讲解中台设计的完整流程。涵盖业务领域分解、中台领域建模、微服务和微前端设计、单元化设计以及业务和数据如何融合等内容。
　　第六部分总结（第23～24章）
　　结合作者多年的设计经验和思考，阐述单体应用向微服务架构的演进策略、如何避免陷入DDD设计的常见误区、微服务设计原则以及分布式架构下的关键设计等内容。

關於作者：

克里斯·理查森（Chris Richardson），世界著名的软件大师，《POJOs in Action》等技术名著的作者，也是著名开源项目Cloud Foundry和Eventuate的创始人。他的研究领域包括微服务架构设计、分布式数据管理、事件驱动的应用架构、领域驱动设计、持续交付、Spring框架、Scala、NoSQL数据库等。
　　
　　喻勇，在技术圈驰骋多年，曾担任过微软技术布道师，VMware Cloud Foundry生态建设负责人，并有幸带领了国内容器技术的创业浪潮。目前定居加拿大，关注微服务架构、云原生应用等领域。
　　Chris与喻勇曾在VMware全球开发者关系团队共事多年，现在他们合作为国内企业客户提供微服务相关的咨询和培训服务，他们的中文网站是：www.chrisrichardson.cn。
　　
　　欧创新，某大型保险公司资深架构师，拥有十多年软件架构设计经验。热衷于DDD、中台和分布式微服务架构设计。在DDD、中台和分布式微服务架构设计方面有深厚的积累，擅长分布式微服务架构设计。
　　极客时间《DDD实战课》专栏作者，在InfoQ发表过多篇关于DDD、中台、微服务和微前端技术实践的有深度和影响力的文章。
　　
　　邓頔，某大型保险公司高级工程师，全国青年岗位能手。致力于基于DDD的企业级中台微服务架构改造实践，精通前端开发相关技术栈，拥有丰富的企业级微前端实战经验。

《微服务架构设计模式/架构师书库》：
写给中文版读者的话
译者序
中文版序一
中文版序二
前言
引言
第1章逃离单体地狱
1．1 迈向单体地狱的漫长旅程
1．1．1 FTGO应用程序的架构
1．1．2 单体架构的好处
1．1．3 什么是单体地狱
1．2 为什么本书与你有关
1．3 你会在本书中学到什么
1．4 拯救之道：微服务架构
1．4．1 扩展立方体和服务
1．4．2 微服务架构作为模块化的一种形式
1．4．3 每个服务都拥有自己的数据库
1．4．4 FTGO的微服务架构
1．4．5 微服务架构与SOA的异同
1．5 微服务架构的好处和弊端
1．5．1 微服务架构的好处
1．5．2 微服务架构的弊端
1．6 微服务架构的模式语言
1．6．1 微服务架构并不是“银弹”
1．6．2 模式和模式语言
1．6．3 微服务架构的模式语言概述
1．7 微服务之上：流程和组织
1．7．1 进行软件开发和交付的组织
1．7．2 进行软件开发和交付的流程
1．7．3 采用微服务架构时的人为因素
第2章服务的拆分策略
2．1 微服务架构到底是什么
2．1．1 软件架构是什么，为什么它如此重要
2．1．2 什么是架构的风格
2．1．3 微服务架构是一种架构风格
2．2 为应用程序定义微服务架构
2．2．1 识别系统操作
2．2．2 根据业务能力进行服务拆分
2．2．3 根据子域进行服务拆分
2．2．4 拆分的指导原则
2．2．5 拆分单体应用为服务的难点
2．2．6 定义服务API
第3章微服务架构中的进程间通信
3．1 微服务架构中的进程间通信概述
3．1．1 交互方式
3．1．2 在微服务架构中定义API
3．1．3 API的演化
3．1．4 消息的格式
……
第4章使用Saga管理事务
第5章微服务架构中的业务逻辑设计
第6章使用事件溯源开发业务逻辑
第7章在微服务架构中实现查询
第8章外部API模式
第9章微服务架构中的测试策略（上）
第10章微服务架构中的测试策略（下）
第11章开发面向生产环境的微服务应用
第12章部署微服务应用
第13章微服务架构的重构策略
《中台架构与实现（基于DDD和微服务）》：
序1
序2 为不确定而架构
前言
绪论
部分认识中台
第1章数字化中台初步认识与建设策略
1．1 平台是中台吗
1．2 中台到底是什么
1．3 传统企业中台的建设策略
1．4 如何实现前中后台的协同
1．4．1 前台
1．4．2 中台
1．4．3 后台
1．5 本章小结
第2章企业中台能力框架
2．1 中台能力总体框架
2．2 业务中台
2．3 数据中台
2．4 技术中台
2．5 研发运营
2．6 云平台
2．7 能力聚合
2．8 组织架构及中台建设方法
2．9 本章小结
第3章微服务设计为什么要选择DDD
3．1 软件架构的演进史
3．2 微服务拆分和设计的困境
3．3 为什么DDD适合微服务
3．4 本章小结
第4章 DDD、中台和微服务的关系
4．1 DDD和中台的本质
4．2 DDD、中台和微服务的协作
4．3 如何完成中台业务建模
4．4 本章小结
……
第二部分 DDD基本原理
第5章领域和子域：有效分解问题域
第6章限界上下文：定义领域边界的利器
第7章实体和值对象：领域模型的基础单元
第8章聚合和聚合根：怎样设计聚合
第9章领域事件：解耦微服务的关键
第10章 DDD分层架构
第11章几种微服务架构模型对比分析
第三部分中台领域建模与微服务设计
第12章如何用事件风暴构建领域模型
第13章如何用DDD重构中台业务模型
第14章如何用DDD设计微服务代码模型
第15章如何保证领域模型与代码模型一致
第17章服务和数据在微服务各层的协作
第18章基于DDD的微服务设计实例
第19章基于DDD的微服务代码详解
第四部分前端设计
第20章微前端架构理念与技术实践
第21章微前端：微服务的搭档
第五部分中台设计案例
第22章中台战略下的保险订单化设计
第六部分总结
第23章微服务拆分和设计原则
第24章分布式架构的关键设计
结束语

內容試閱：

《中台架构与实现：基于DDD和微服务》
为何写作本书
当前基于微服务架构来构建企业级应用已成为业界趋势。微服务架构很好地实现了应用解耦，可以更好地实现应用上云，解决单体应用扩展和弹性伸缩能力不足的问题。鉴于众多互联网企业微服务架构转型后带来的成功和收益，越来越多的传统企业也开始从单体架构向微服务架构转型。但在演进的过程中，微服务到底应该怎样拆分和设计，拆多小才算合理？这已经成为业内重点关注的话题。
继阿里巴巴成功完成中台战略转型后，很多大型企业也紧随其后开启了中台数字化转型。作为中台，需要将通用的业务能力沉淀到中台业务模型，实现企业级业务能力复用。中台建设面临的首要问题是如何按照可复用原则完成企业级业务模型重构。而在中台落地时，又会面临微服务拆分和设计的问题。这两个问题一前一后，对任何企业来说都是不小的挑战。
现在市面上关于微服务开发和技术的学习资料非常多。但在中台数字化转型过程中，关于如何进行业务领域边界划分，如何完成中台领域建模实现能力复用，如何完成单体应用拆分和微服务设计，如何实现前中后台的协同设计等，可参考和借鉴的资料并不是很多，即便有一些，真正理解和实施起来也是困难重重。
中台越来越火，微服务越来越热，参与的人也越来越多，但是市面上一直没有一套体系化的理论与方法来指导中台和微服务建设。那是否有成熟的理论或方法来指导中台领域建模以及微服务拆分和设计呢？答案是肯定的，那就是DDD（Domain Driven Design，领域驱动设计）。
2003年埃里克·埃文斯（Eric Evans）出版了《领域驱动设计》，从此DDD诞生。在沉寂了十多年后，随着微服务架构的流行，DDD强势崛起，成为很多企业微服务的主流设计方法。DDD首先从业务领域入手，划分业务领域边界，采用事件风暴工作坊方法，分析并提取业务场景中的实体、值对象、聚合根、聚合、领域事件等领域对象，根据限界上下文边界构建领域模型，将领域模型作为微服务设计的输入，进而完成微服务详细设计。用DDD方法设计出来的微服务，业务和应用边界非常清晰，符合“高内聚，低耦合”的设计原则，可以轻松适应业务模型变化和微服务架构演进。
微服务与DDD的共生关系主要从两方面来体现。一方面是微服务提倡将应用进行服务化拆分，通过业务领域边界实现应用服务边界的划分。另一方面，DDD恰好提供了一种基于业务限界上下文边界来实现微服务“高内聚，低耦合”的服务构建方法。将两者合理搭配使用，研发组织可以轻松实现面向服务的设计，享受持续交付与架构演进。
DDD与微服务，乃至中台设计的结合，目前仍是一个非常新的领域。很多人可能并不清楚它们的关系，不知道该如何利用DDD来完成中台和微服务的协同设计。
基于上述背景，本书聚焦业务中台设计和建设，系统地阐述了基于DDD的中台和微服务建设的方法体系，主要包括中台业务边界划分和领域模型构建，微服务、微前端设计理念与实践，以及如何进行前中后台的协同设计和单元化设计等内容。

本书主要特点
纵观全书，本书具有以下6个显著特点。
1）深入浅出，浅显易懂。本书打破了常规采用大量理论知识堆砌来讲解DDD知识的方式，用大量场景化的案例类比和分析，带你深入理解DDD基础知识和核心设计思想，解决了DDD知识体系过于庞大而难以理解和微服务落地困难的问题。
2）结构合理，从DDD理论到微服务实践完美结合。本书从理解DDD基础理论知识和核心设计思想出发，结合多个企业级业务场景，完成了DDD全流程的领域建模和微服务设计，对服务设计与技术落地等实现细节进行了大量的示例说明。结合案例设计，完成了微服务代码的开发，并对代码实现进行了详细的代码分析和讲解，帮助你避免开发过程常见问题的发生。可以说，本书从理论中来，到实践中去，能够有效指导中台和微服务的设计和开发。
3）化繁为简，从宏观业务分析到微观技术实现面面俱到。DDD、微服务与中台三者中的任何一项，放在任何一家企业，都是一项非常庞杂且复杂度非常高的工作。本书分别从DDD设计视角和中台建设视角进行对比分析，梳理了DDD、微服务与中台三者之间的协作关系。特别强调从业务领域出发，利用DDD战略设计和战术设计方法同时指导中台领域建模和微服务设计。可以说，DDD是中台和微服务设计的指导方法，而微服务则是中台的技术实现，它们就是这样的铁三角协作关系。我们将三者结合，从企业领域到子域的战略设计、宏观业务领域边界划分到微服务内底层领域对象的逐级细化设计，降低软件产品建设的复杂度，实现从宏观战略到技术实现细节的无缝衔接。
4）案例翔实，建立了企业级的中台建设方法体系。本书涵盖了前台、中台和后台建设及设计的完整方法，建立了一套标准的中台领域建模和微服务设计方法及流程，可以很好地指导企业完成中台设计和微服务落地。通过大量复杂业务场景的详细案例设计和分析，将DDD、中台和微服务三者结合，以近乎手把手的方式详细介绍了中台和微服务的设计方法和步骤。在中台业务建模时，你可以利用DDD战略设计，分解业务领域，从事件风暴入手，根据限界上下文边界构建可复用的中台领域模型。在中台落地时，你可以利用DDD战术设计，根据领域模型指导完成微服务和微前端设计和落地。
5）问题导向，一切都是为了解决实际问题。本书引入了大量成熟的中台与前台相关技术和设计方法，体系化地解决了企业中台建设过程中前台、中台和后台的协同设计，以及共享、联通与融合的问题。引入微前端设计思想，解决中台微服务化后，前端仍存在因单体而产生的前端集成和开发复杂的问题。为此，书中首次提出了基于领域模型的、单元化的设计思想，以领域模型为基准，向上构建微前端以实现领域模型的前端页面逻辑，向下构建微服务以实现领域模型的核心领域逻辑。将微服务和微前端集成组合为组件级业务单元，实现微前端页面逻辑和微服务接口能力的企业级复用。设计时，我始终强调应结合企业实际情况，选择合适的方法和工具解决企业的实际问题，具体情况具体分析，灵活、体系化地运用技术和方法，通过常见问题分析和经验总结，避免陷入常见设计误区。
6）文字简洁，易于阅读。本书部分内容来源于我在极客时间的专栏《DDD实战课》，整体采用与读者交互的行文风格，经过多重打磨，文字有活力，内容不刻板，更加简洁易懂。

本书阅读对象
本书是一本关于中台、微服务和微前端设计与建设的书，采用了DDD设计思想和方法，适合的阅读对象主要分为下面几类：
从事企业数字化转型的企业管理者；
从事企业技术架构和微服务设计的架构师；
从事企业业务架构设计和业务建模的业务人员；
从事微服务设计和开发的高级技术人员；
希望从事中台和微服务架构设计的人员；
对DDD、微服务和中台设计感兴趣的学习者。

如何阅读本书
本书主要包含24章，共分为6部分。
部分　认识中台（第1～4章）
本部分包括4章，主要介绍中台相关背景知识，认识并理解中台的真正含义，从业务中台、数据中台、技术中台以及与之匹配的组织架构等多个方面分析传统企业中台转型应该具备的能力，带你初步了解DDD是如何指导中台和微服务设计，并厘清它们的协作关系的。
第二部分　DDD基本原理（第5～11章）
为了让你能够更加深刻地理解DDD，本部分通过一些浅显易懂的案例，帮助你学习并深刻理解DDD的核心基础知识、设计思想、原则和方法等内容，了解它们之间的协作和依赖关系，解决DDD概念理解困难的问题，做好中台实践前的准备工作。本部分包括7章，主要讲解DDD的关键核心知识体系，包括领域、子域、核心子域、通用子域、支撑子域、限界上下文、实体、值对象、聚合、聚合根、领域事件和DDD分层架构等知识。
第三部分　中台领域建模与微服务设计（第12～19章）
本部分包括8章，主要介绍DDD是如何通过战略设计构建中台业务模型，以及如何通过战术设计指导微服务拆分和设计的。在这一部分，我会用多个实际案例，带你用DDD方法完成中台和微服务的全流程设计，深刻理解DDD在中台领域建模与微服务设计中的步骤、方法、设计思想和价值。
1）了解如何用事件风暴方法构建领域模型。
2）了解如何用DDD设计思想构建企业级可复用的中台业务模型。
3）了解如何用DDD设计微服务代码模型，如何将领域模型映射到微服务以建立领域模型与微服务代码模型的映射关系，如何完成微服务架构演进等。
后用一个案例将DDD所有知识点串联在一起，带你深入了解如何用DDD的设计方法完成领域建模与微服务设计的全流程，并对代码示例进行了详细分析和讲解。
第四部分　前端设计（第20章和第21章）
本部分包括两章，主要介绍微前端的设计思想，通过前端微服务化和单元化的设计思想，解决业务中台建设完成后前端应用解耦和前后端服务集成复杂的难点。书中阐述了如何借鉴微服务的设计思想来解构前端应用，实现前端应用的拆分解耦，并结合实践介绍前端架构的转型策略与技术落地。
另外，本部分还探讨了基于领域模型的单元化设计方法。通过微服务与微前端组合后的单元化设计，既可以降低企业级前台应用集成的复杂度，又可以让企业具有更强的产品快速发布和业务响应能力。这种能力能给我们的团队组建、研发模式、业务能力发布等带来非常大的价值。
第五部分　中台设计案例（第22章）
本部分包括一章，通过保险订单化设计案例，采用自顶向下的领域建模策略，带你走一遍中台设计的完整流程。案例中涵盖业务领域分解、中台领域建模、微服务和微前端设计、单元化设计以及如何实现业务和数据融合等内容，希望能够帮助你加深对DDD、中台、微服务和微前端等知识体系、设计思想和技术体系的全面理解，更好地投入DDD、中台和微服务建设实践中。
第六部分　总结（第23章和第24章）
本部分是全书的总结，包括两章。书中结合我多年的设计经验和思考，带你了解单体应用向微服务架构的演进策略，如何避免陷入DDD设计的常见误区，微服务设计原则以及分布式架构下的关键设计等内容。

勘误
由于时间仓促，加之水平有限，错误和疏漏之处在所难免。在此，诚恳地期待你的批评指正。如果你有任何疑问、技术交流需求或建议，可以直接发送至邮箱（chuangxinou@163.com），或关注微信公众号“中台架构与实现”，我们会及时反馈。
致谢
感谢ThoughtWorks强大的技术团队和丰富的文档资料。ThoughtWorks对DDD的大力宣传和推广，给我们提供了大量的学习和参考资料。技术雷达可以让我们了解的技术趋势和研究方向。总之，受益匪浅。
感谢机械工业出版社华章公司副总编辑杨福川老师和编辑李艺老师，他们在我们写作过程中提供了大量的帮助和支持，付出了辛勤劳动，指导我们顺利完成本书。
感谢极客时间总编辑郭蕾老师和专栏主编李佳、王冬青老师指导我顺利完成了《DDD实战课》专栏，有了专栏的技术和文字积累，我才有足够的信心完成本书。
感谢本书合著者邓頔提供的微前端实施经验。他负责编写本书微前端部分章节内容，并为本书的策划、内容、实践和校对提供了宝贵建议和意见。
特别感谢PICC各位领导和同事在本书编写过程中提供的帮助和支持！
在本书编写过程中，ThoughtWorks中国区技术战略咨询服务负责人、首席架构师王威（David）老师给予了大量指导并为本书写序。在此表示感谢！

欧创新

◆推荐序◆
序　　1
个人对DDD一直比较有兴趣，也包括企业架构设计、在DDD之前的领域分析如分析模式、彩色建模等。如果把软件按照相对的“稳定性”来排序，领域层＞应用层＞界面层。以营销为例，撬动用户的还是老三样：卡、券、积分，本质就是营销资产资金流，而从产品包装上可以策划满减、满返、2件折扣、限时优惠、限定电商全场消费、限定活动线下商超、限定品类等活动，不一而足。领域层是相对稳定的，应用层（业务逻辑层和具体规则）可以有多种变化，而广义界面层的实质包括产品包装、交互等可以有更多的互动玩法。窃以为，领域分析的价值所在就是寻求“千变万化”中相对的“稳定性、性”，然后通过合理的架构分层及抽象隔离的业务复杂度和技术复杂度，隔离业务领域的稳定性和易变性，从架构上精巧、快速地支持业务的变化。技术为业务服务，但绝不是业务到IT的简单翻译。
欧老师精于保险业务，对于DDD也有自己的理解和看法。从经典的DDD战略设计到基于微服务的战术设计/实现的案例，本书给出了全面的参考案例。知行合一，则“限界上下文”“实体”“值对象”“聚合”“事件”“事务一致性”等都不再神秘。本书也有一些可喜的创见，如对于“微前端”和“业务单元化”的提炼。本书以保险订单化销售业务领域为例，采用自顶向下策略，完成保险部分业务领域的中台设计，带领读者了解中台设计全流程，理解DDD、业务中台、微服务、微前端与单元化设计的关系以及它们的核心设计思想。
本书价值不菲，强烈推荐。无论对于DDD的初学者，还是DDD的资深人士，都有相应的启发。写作者的安慰莫过于读者觉得有价值，有收获。祝大家阅读愉快！

右军，《深入分布式缓存》《程序员的三门课》联合作者　　

序　　2
为不确定而架构
在过去的几年中，因为工作的关系，我同很多科技类企业和组织合作过。这些企业和组织分布在不同的行业和地区，从电信、金融到物流供应链，从国内到全球各地。几乎所有技术行业的同人在谈到未来的时候，都流露出了很强的改变意愿和紧迫感。例如今年出现的新冠肺炎疫情，以及围绕疫情在全球范围出现的一系列连锁反应，都导致大家逐渐形成了一个共识：世界已经从根本上改变，未来20年将要发生的事情，可能是我们今天根本无法想象的。在这样的背景下，每一个组织都希望能够通过加大科技的投入，赋能自己的客户和业务，从而做好应对未知挑战的准备。
另一方面，软件“侵蚀”世界已经是不争的事实，在国内的很多城市中，恐怕已经很难想象完全脱离软件的生活会是什么样子。即使我们不谈“不可见”的嵌入式软件和网络控制类软件，仅仅脱离了智能手机以及建于其上的各种App，我们熟悉的生活似乎将无法运转下去。新兴的科技公司，在利用软件技术打造新的场景，培养用户的使用习惯，创造新的业务价值的同时，也在倒逼前辈们对传统的业务进行数字化改造，以适应新时代下技术的变化速度。同时，科技公司又将自己的实践标准化、产品化，希望通过与传统企业的合作，加速整个行业变革的进程。20年前的SOA架构、6年前的微服务架构和3年前阿里的“中台”都是这种模式的很好代表。
客户习惯的改变，技术的发展和快速演进，以及在一些行业出现的外力作用，都带来了价值、场景、技术、政策的不确定性。所有不确定性的综合，使得软件的构建过程一定会面对这样的窘境：软件永远跟不上业务变化。为了解决这样的问题，业界的前辈们一直在通过管理、技术、工具平台等多种维度来解决同一个问题：如何使软件的构建具备更高的响应力。敏捷、精益、DevOps、效能平台都是为解决这个问题而出现的解决方案。在这个过程中，“如何在复杂业务场景下设计软件”逐渐成为架构师们关注的焦点。领域驱动设计（以下简称DDD）的提出，恰恰解决了这一问题。但是在2010年之前，因为单体应用仍然占据主流地位，DDD“曲高和寡”。直到“微服务”的出现，才消除了原来单体应用的桎梏，使得DDD成为架构师们都在讨论的软件架构设计标准实践。
近年来，DDD在国内的影响力逐年增大。我仍然记得在2015年前后和企业交流的时候，当时大家对于什么是DDD完全摸不着头脑，很多组织直接把源自“产品线工程”的“领域工程”和DDD作为相同的概念加以实践。2017年我们举办了届DDD中国峰会，那时有很多参与的同行对于DDD如何在自己的组织、场景中落地还存有这样或那样的疑虑。而到2019年的第三届峰会时，大家更多是带着问题和经验来和业界的同行们一起交流心得，探索在新场景下如何利用DDD带来更多的价值。
我和欧创新老师正是在这样的背景下认识的。欧老师在过去几年中将DDD的思想、微服务以及中台的理念同自己企业的实际相结合，积累了丰富的实践经验。每一次和欧老师交流，我都能学到很多东西。当欧老师找到我为这本书作序的时候，我既受宠若惊，又诚惶诚恐。在拜读完本书后，我惊讶于在这么短的时间内，欧老师不仅将自己获得的经验提炼总结，还用通俗易懂的语言和丰富的案例，将DDD、微服务、中台的概念和围绕在它们周围的实践讲述得如此详细。本书确实是业界难得的一个针对架构设计和中台转型的技术层面的总结，我个人从中获益匪浅，相信本书的读者朋友会和我有同样的体会。

王威
ThoughtWorks中国区技术战略咨询服务负责人

《微服务架构设计模式》
【写给中文版读者的话】
7年前，我带着对美食和技术的热情，开始了我的首次中国之旅。在那之前，我对中国的美食和软件社区都知之甚少。7年之后，经过多次中国之行，我对这两者都有了深刻的认识：我爱上了地道的中国菜，也对中国的软件开发者印象深刻。
2012年我首次访问中国，参加我在VMware公司的同事Frank举办的几场开发者会议。我一口气在北京和上海做了好几场演讲，包括云计算、Cloud Foundry、Node.js、Spring、NoSQL数据库，当然，还有微服务。我与2000多位参加会议的来宾讨论Cloud Foundry，这次旅行让我意识到中国开发者社区的规模和热情，也让我有机会品尝了地道的中国菜。我甚至还忙里偷闲，在北京参加了一天中餐烹饪课程。
2013年，Frank再次邀请我来到北京，参加中国首场SpringOne大会，发表关于微服务和NoSQL的演讲。这次旅行的亮点是访问豆瓣和百度，这是我与中国科技公司的次近距离接触。他们的规模和创新技术都给我留下了非常深刻的印象。在这次旅行中，我参观了北京奥林匹克公园，回忆了曾在这里举行的2008年北京奥运会开幕式。我也抓住机会，继续“进修”中餐烹饪课程。
这次大会结束后不久，我离开VMware公司，再次走上了创业的道路。我搭建了microservices.io网站，撰写了大量的文章和课件，搭乘我钟爱的United Airlines，为世界各地的客户提供微服务架构咨询和培训服务。我还创立了eventuate.io公司，发布了用于微服务架构的数据访问框架。这些工作促成了我和Frank的再度合作，我有幸在2016年4月和8月再次访问中国。从那以后，我在中美之间多次往返，帮助中国的企业客户实施微服务架构。这些公司的业务多种多样，包括保险、汽车制造、电信和企业软件。地域上的跨度，也从北京和上海延伸到了深圳、武汉和杭州。在这些旅行中，我爱上了烤鱼、新疆菜和蒙古菜。
中国企业和开发者对微服务架构的热情让我印象深刻。但如同我给所有客户的忠告一样，我想对本书的读者说：
，要记住微服务不是解决所有问题的“银弹”。
第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。
第三，关注微服务的本质，即服务的分解和定义，而不是技术，如容器和其他工具。
第四，确保你的服务松耦合，并且可以独立开发、测试和部署，不要搞成分布式单体（Distributed Monolith），那将会是巨大的灾难。
第五，也是重要的，不能只是在技术上采用微服务架构。拥抱DevOps的原则和实践，在组织结构上实现跨职能的自治团队，这必不可少。
还必须记住：实现微服务架构并不是你的目标。你的目标是加速大型复杂应用程序的开发。
后，我要感谢中国的所有客户，让我有机会与你们探讨微服务。我还要感谢那些让我能够讨论技术而不用学说中文（这可比微服务难多了）的同传翻译。我希望你会喜欢阅读这本书，它会教你如何成功开发微服务。我期待着再次访问中国，与我的读者见面，帮助更多企业客户实施微服务架构。

Chris Richardson
2019年2月13日

【中文版序一】
良马难乘，然可以任重致远；良才难令，然可以致君见尊。
—墨子
曾经有一个客户把他们遇到的微服务问题列出来给我看，当时我觉得头绪万千但又无从说起，于是想到了墨子的这句话。
如果现在有人问我这个问题，那么我会推荐他们一边看Chris Richardson的这本书，一边在实践中尝试和体验各种模式的优势与特点，然后大家一起讨论遇到的问题并提出解决思路。
大概从五六年前开始，我在工作中越来越多地谈到了微服务，并参与了一些客户应用的微服务改造，其中不乏成功的例子，当然也有没达到预期的情况。随着网络基础设施的高速发展，以及越来越多的企业和组织需要通过互联网提供服务，在考虑构建可以支持海量请求以及多变业务的软件平台时，微服务架构成为多数人的。微服务架构的出现是符合事物发展规律的：当问题足够大、有足够多的不确定性因素时，人们习惯把大的问题拆分成小的问题，通过分割、抽象和重用小而可靠的功能模块来构建整体的方案。但是当这些小的、可重用的部分越来越多时，又会出现新的问题。在相似的阶段，人们遇到的问题通常也是相似的，这个时候我们需要一些共识，需要用一些通用的词汇来描述问题以及解题思路和方案，这也是人们知识的总结。微服务模式就是这样一种总结和概括，是一种可以通用的共识，用于描述微服务领域中的问题及解决方案、方法和思路。这是我向大家推荐这本书的理由之一：讨论微服务的时候，这本书提供了必要的共同语言。
在和Chris交流时，我深深地被他高度的思维能力所折服，尤其是对问题的深刻理解和对解决思路的高度抽象。与有敏锐思维且有高度抽象能力的人讨论问题是件快乐的事情，他总是能把自己的经验和概括总结出的信息用清晰的方式表述出来。现在，他把关于微服务的这些抽象整理成了这本书。可以说，这是广大微服务相关工作人员的福音。在这本书里，不仅有微服务领域已经识别出来的问题、解决思路和解决方案，也有相应的代码例子。这就使得高度抽象的内容有了非常具体的表现，可以帮助我们在遇到问题之前就了解可能的潜在问题；有些代码例子甚至是可以直接使用的。这种知行合一的能力，是我钦佩Chris的又一个重要原因，也是我向大家推荐这本书的理由之二：这本书可以帮助微服务相关人员构建知行合一的能力。
在一次关于“架构的关键是什么”的讨论中，我们和Chris很快达成了共识：架构就是取舍，进而架构师就是做出取舍的人。大家都认同，做架构的人的特征之一应该是“Independent”（独立），这也是我选择做独立解决方案进而设计产品的重要原因。在我们看来，只有独立才有可能让我们在做架构设计时做出中立和独特的方案。面对问题时，大多数人会希望有人可以给出“正确的”建议，但是多数时候，困扰人们的不是“什么才是正确的”，而是“取舍之间”。这正是我推荐这本书的理由之三：这是一本可以帮你在设计微服务架构时做出取舍的书，它能在你处理微服务相关问题左右为难的时候给你提供参考和建议。
我们生活在一个高速发展的时代，微服务领域的技术、产品、模式日新月异，我们非常有幸参与和见证这个时代的发展。我们从解决昨天的问题里走出来，又走向更多的问题。在这个过程中，我们解决的问题的规模和复杂度都是成倍提升的。相信很多和我一样喜欢体验这种从无到有的过程、喜欢亲手解决问题的成就感、喜欢用独立思维去面对问题的人，都会喜欢这本书。在此，再次对ChrisRichardson先生表示感谢，他为这个领域贡献了宝贵的知识财富。

蔡书
独立顾问，PolarisTech联合创始人

【中文版序二】
国际数据公司（IDC）研究表明，2018～2021年间，全球数字化转型方面的直接支出将达到5.9万亿美元。埃森哲（Accenture）指出，目前在中国仅有7%的企业成功地实现了数字化转型，而这些成功转型的公司，它们的业绩复合增长率是尚未转型的同行企业的5倍之多。
数字化转型依赖技术创新。美国风险投资机构Work-Bench在《2018企业软件调研年报》中推论：以微服务为代表的云原生技术是帮助企业实现有效数字化转型的技术途径。数字化转型背景下客户的预期越来越高，需要企业的线上业务能快速迭代满足动态的市场需求，并能弹性扩展应对业务的突发式增长；而微服务由于其敏捷灵活等特性成了满足这些诉求的答案。因此，微服务可成为企业进行数字化转型的强力催化剂。
微服务的概念虽然直观易懂，但“细节是魔鬼”，微服务在实操落地的环节中存在诸多挑战。我们在为企业提供PaaS、人工智能、云原生平台等数字化转型解决方案时也发现，企业实现云原生，并充分利用PaaS能力的步，往往是对已有应用架构进行现代化微服务改造，而如何进行微服务拆分、设计微服务逻辑、实现微服务治理等实操问题成为很大的挑战。
本书英文原作由微服务权威架构师ChrisRichardson先生所著。书中既包含了微服务的原理、原则，又包含了实际落地中的架构设计模式；既包含可举一反三的理念和概念，也包含类似领域驱动设计、Saga实现事务操作、CQRS构建事件驱动系统等具体可套用的范式。本书可以帮助读者把传统的单体巨石型应用循序渐进地改造为微服务架构，从微服务的拆分，微服务架构下业务逻辑的设计以及事务、API、通信等的实现，一直到微服务系统的测试与生产上线，帮助读者建立从无到有的完整微服务系统搭建的生命周期。
本书译者在云计算、云原生与微服务领域有多年实践经验和建树，译文既精确地还原了原著的内容，又结合译者自身的理解，让中文版本更加通俗易懂。虽身在云计算行业多年，我在通读译著后依然受益匪浅。相信本书对于企业CIO推动公司数字化转型战略、软件开发者提升自身技术架构功力，以及云原生爱好者以微服务切入的云原生体系，都有着极其重要的实践指导意义。

张鑫
才云科技CEO

【译者序】
2012年年初，我有幸加入了VMware公司的CloudFoundry团队，与ChrisRichardson、PatrickChanezon、JoshLong等业界大咖共事，在全球范围内开展CloudFoundry开发者社区和生态建设工作。7年前，云计算的市场格局与现在大为不同。那时，IaaS正高歌猛进，PaaS的价值仍旧备受质疑，“十二原则”还不为人所知，云端分布式系统的架构演化也正“摸着石头过河”。在这个时候，ChrisRichardson率先在业界提出了“FunctionalDecomposition”（功能性拆分）的概念，提出云计算环境下的分布式软件，应该按照功能性拆分的方式进行架构重构。这个想法与稍后业界公认的“微服务”概念不谋而合。
在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日

【前　　言】
我很喜欢的格言之一是：
未来已经到来，只是还没有平均分布。
—威廉·吉布森，科幻小说作家
这句话的实质是在说，新的想法和技术需要一段时间才能通过社区传播开来并被广泛采用。我发现并深入关注微服务的故事，就是新思想缓慢扩散的一个极好例子。这个故事始于 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经常难以跟上业务需求。大家都很想知道如何采用微服务架构来解决所有这些问题。
本书的目标就是回答这个问题。它将使读者对微服务架构、它的好处和弊端，以及应该何时使用微服务架构有一个很好的理解。书中描述了如何解决我们将面临的众多架构设计挑战，包括如何管理分布式数据，还介绍了如何将单体应用程序重构为微服务架构。但本书并不是鼓吹微服务架构的宣言。相反，它的内容围绕着一系列模式进行展开。模式是在特定上下文中发生的问题的可重用解决方案。模式的优点在于，除了描述解决方案的好处之外，还描述了成功实施解决方案时必须克服的弊端和问题。根据我的经验，在选择解决方案时，这种客观性会带来更好的决策。我希望你会喜欢阅读这本书，它会教你如何成功开发基于微服务架构的应用程序。

書城介紹　 \|　合作申請　\|　索要書目　 \|　新手入門　\|　聯絡方式　 \|　幫助中心　\|　找書說明　 \|　送貨方式　\|　付款方式	香港用户　 \|　台灣用户　\|　海外用户

	megBook.com.hk
Copyright © 2013 - 2025 （香港）大書城有限公司　 All Rights Reserved.