微服务下的领域驱动设计

本书以实战理念为主旨, 对领域驱动设计的核心内容进行了全面解读。 书籍主要由两部分内容构成: 战略与战术。 第一部分以子域和限界为核心, 并通过案例的形式介绍了如何在现实中将其进行实践的知识; 第二部分则围绕应用架构、 聚合、 实体、 值对象、 领域服务等概念展开讲解, 重点描述了它们在应用中所充当的角色以及使用限制。 除此之外, 作者也根据自身的经验对一些常见的设计理论或设计模式进行了概括和总结, 如面向对象、 工作单元、Saga 分布式事务等。 尽管书中案例使用了Java 语言进行表达, 但并不会影响到读者的阅读体验。

本书的受众群体为软件工程师、 系统架构师、 需求分析师或计算机相关专业的在校师生等。

本书通过生动的案例和实用的指南，向读者展示了如何在实践中进行DDD落地以创造出灵活的、可维护的且具有良好可扩展性的软件系统。无论您是刚入门的研发人员还是经验丰富的软件工程师，这本书都可为您提供相应的指导，助您成为领域驱动设计领域中驾轻就熟的技术专家。

——亚信科技电信事业部总工程师兼OSS解决方案部总经理 陈友行

DDD不仅是令人着迷的学问，也是解决复杂业务问题的利器。本书作者通过简约但不简单的案例向读者展示了如何将这一抽象性十足的方法理论应用于实践当中，给大家以豁然开朗之感。

——中电福富信息科技有限公司副总经理 林启铵

本书作者以深厚的专业知识和丰富的实践经验为根本，将复杂的技术概念转化为易于理解的思想和语言，巧妙地将抽象的概念运用于具体的案例之中，能够让读者快速领悟DDD的精华。书中的设计技巧和建议，不仅能够帮助您快速掌握理论知识，还能带领您解决实践中的技术挑战，加速技能的提升和自身的成长。

——广东亿迅科技有限公司总工程师 廖小文

为什么要写此书

我小的时候比较喜欢拆家, 和幼年的哈士奇有些类似。 不过经济条件所限, 能拆的东西也仅限于钟表、 收音机这类小的物件儿。 儿时的梦想是成为一名科学家或老师, 不过随着成长, 梦想也逐渐变得更现实起来, 最终选择了与软件设计为伍。

很多人羡慕程序员的高薪与体面, 殊不知我们自嘲为“码农”。 软件设计是一种创造性的活动, 它与艺术创作类似。 自然, 大部分人的职业生涯早期的确都会做一些“搬砖”类的工作, 但我们不应该让其变成一种常态。

我于2007 年接触领域驱动设计(DomainDrivenDesign, 简称: DDD) , 但学习过程并不顺利。 好的方面是伴随着失败, 自己也积累了很多更为务实的知识。 2021 年, 我怀着满满的自信尝试在网上发布一些领域驱动设计相关的文章, 期望能将自己所学的知识进行总结与分享。 这期间有幸认识了北京航空航天大学出版社的编辑, 他们鼓励我将自身所学体系化, 本为玩票性质的事情自此开始偏向了另外一个方向, 成为编写本书的一大诱因。

为什么选择领域驱动设计

进入21 世纪, 人们的生活伴随着互联网的发展有了翻天覆地的变化。 加之智能手机和各类智能设备的催化, 单机软件所带来的满足感已经不能满足人们日常生活与工作的需要。 事物总是有两面性的, 软件的各种功能在满足我们方便使用的同时, 便是其规模和复杂度的急剧扩张, 仅仅是技术知识的爆炸对于精力有限的我们就是一项很大的挑战。

领域驱动设计诞生于21 世纪初, 历经20 余年的发展至今仍活力十足。 越来越多的人开始意识到它的强大和先进, 其思想被应用到各类大型软件项目中。 但现实的情况却很残酷: 我们都知道它很强大, 但我们不想用。 客观来讲, DDD 诞生之时的确是“超时代”的。 有些理论过于理想化并不能在真实的项目中被轻易实践, 比如“限界上下文”。 没有现代微服务技术的加持, 我们很难将其落地。

软件系统越发复杂, 使得企业不得不背负更高的建设与运营成本,DDD 作为应对软件复杂之道是解决这一问题的有力武器。 与此同时, 时代的发展以及技术的推陈出新也让 DDD 真正地有了属于自己的舞台, 这是我们选择它的原因。

如何使用本书

本书主要适用于软件设计人员和研发人员, 您需要至少了解一门面向对象开发语言, 如 C# 、Java。 当然, 这些仅仅是基础, 软件设计并不只是某一门特定的学问而是各类知识的集成。 所以想要无障碍阅读本书, 您还需要了解一些简单的设计模式以及UML 相关的内容。

本书分为战略与战术两部分, 后者所涉及的知识虽与前者有关系, 但亦可独立存在。 如果您初入软件设计行业或从事本行业时间尚短, 建议先从第二部分读起。 战略相关的知识理论色彩较浓厚, 是劝退读者的最佳武器; 战术部分则侧重于各种技术的讲解, 这才是程序员最喜欢的内容。 当您确信自己能够被 DDD 吸引的时候, 可再回到第一部分, 避免让自己的学习旅程出现“夭折”。

除技术人员之外, 项目经理、 架构师或需求分析师也可成为本书的读者, 尤其是战

略部分。 如果您的角色处于上述工种, 可以考虑从第一部分读起, 以学习如何站在更高的战略角度去了解系统的全貌; 学习如何将一个大的系统进行划小建设; 学习如何有效安排各类资源, 即钱、 事、 物。

与其说领域驱动设计是一种技术, 不如将其看成设计思想更为合适。 笔者资历尚浅, 本书其实是一种尝试, 即: 通过个人的理解并伴以务实的态度对领域驱动设计这一门学问进行个性化解读。 有理解或表达不当之处, 请读者在求同存异的同时, 有取舍地借鉴书中内容。

编 者

第一部分 沙场秋点兵———战略布局

第1 章 柳暗花明———困境与修身

1 .1 困 境

1 .1 .1 DDD 的野望与尴尬

1 .1 .2 何以解忧

1 .2 山重水复

1 .2.1 软件中的熵增

1 .2.2 抑制熵增速率

1 .3 修 行

1 .3 .1 管理者的修行

1 .3 .2 软件工程师的修行

总 结

第2 章 比翼连枝———领域驱动设计与微服务

2.1 软件革命———微服务的兴起

2.2 更进一步———DDD 的百尺竿头

2.3 差 异

2.4 对微服务的反思

2.5 DDD 与微服务的秦晋之好

2.5 .1 业务中台的概念

2.5 .2 助力服务划分

总 结

第3 章 战略划小———领域与子域

3 .1 胸存丘壑

3 .2 领域与子域

3 .3 子域特性

3 .3 .1 分割领域

3 .3 .2 可变的

3 .3 .3 有 界

1微服务下的领域驱动设计

3 .3 .4 可决策资源投入

3 .3 .5 业务高度内聚

3 .4 解读子域

3 .4.1 业务灵魂———核心域

3 .4.2 业务基石———支撑域

3 .4.3 复用之道———通用域

3 .5 识别子域的手段与策略

3 .5 .1 子域设计第一步———业务识别

3 .5 .2 子域设计第二步———子域打标

3 .5 .3 子域设计第三步———子域精化

3 .5 .4 子域划分策略总结

总 结

第4 章 确定疆域———限界上下文(Bounded Context)

4.1 通用语言

4.1 .1 通用语言的作用

4.1 .2 通用语言的特性

4.1 .3 通用语言的使用方式

4.2 限界上下文的内涵 2

4.2.1 限 界

4.2.2 上下文

4.2.3 限界上下文与子域

4.3 限界上下文的特性

4.3 .1 物理划分

4.3 .2 根据子域推导

4.3 .3 限定边界

4.3 .4 承上启下

4.3 .5 具备技术性

4.4 限界上下文中的元素

4.4.1 领域模型

4.4.2 用例控制能力

4.4.3 数据存取能力

4.4.4 表现能力

4.4.5 数据转换

4.4.6 部署能力

4.4.7 交互支撑能力

4.5 限界上下文的来源

4.5 .1 基于子域

4.5 .2 基于非功能性需求

4.6 案 例

4.7 限界上下文的粒度与规模

4.8 限界上下文间的通信

4.8.1 限界上下文的集成方式

4.8.2 限界上下文映射案例

4.9 再谈隔离

4.10 限界上下文中的业务模型

4.10.1 软件建模

4.10.2 限界上下文与模型的集成

总 结

第二部分 知行合一———战术实践

第5 章 中流砥柱———系统架构(Architecture)

5 .1 对象与服务

5 .1 .1 对 象

5 .1 .2 服 务

5 .2 分层架构

5 .2.1 经典三层架构

5 .2.2 DDD 四层架构

5 .3 洋葱架构与六边形架构

5 .3 .1 认识洋葱架构

5 .3 .2 认识六边形架构

5 .4 命令查询责任分离(CQRS)

5 .4.1 认识 CQRS

5 .4.2 CQRS 的实现

5 .5 事件驱动架构(EDA)

5 .5 .1 认识 EDA

5 .5 .2 EDA 案例

5 .5 .3 EDA 的特色

5 .6 事件溯源(Event Sourcing)

5 .7 事务与数据一致性

5 .8 代码结构

5 .8.1 组织项目

5 .8.2 服务中的代码模型

3微服务下的领域驱动设计

5 .8.3 实 践

总 结

第6 章 举世无双———实体(Entity)

6 .1 认识实体

6 .1 .1 贫血模型与充血模型

6 .1 .2 实体的标识符

6 .1 .3 实体的比较

6 .1 .4 实体的特征

6 .2 实体的行为

6 .2.1 责任主体

6 .2.2 知识掌握程度

6 .2.3 是否可复用

6 .2.4 是否需要多对象协作

6 .2.5 基于高内聚、 低耦合原则

6 .3 实体的构造函数

6 .3 .1 保障对象完整与合法

6 .3 .2 优先使用工厂

6 .3 .3 包含定制构造函数

6 .4 实体设计实践

6 .4.1 设计约束

6 .4.2 实体存取

6 .5 额外的礼物———对象间的关系

6 .5 .1 类图的作用

6 .5 .2 类间的关系

6 .5 .3 类图的粒度

总 结

第7 章 股肱之臣———值对象(Value Object)

7.1 认识值对象

7.1 .1 值对象的含义及作用

7.1 .2 值对象示例

7.1 .3 值对象的作用范围

7.2 值对象的特征

7.2.1 无标识符

7.2.2 修饰某物

7.2.3 构成某物

7.2.4 概念整体

7.2.5 不可变

7.2.6 无副作用

7.3 值对象的构造

7.4 值对象的存取

7.4.1 附加到实体表

7.4.2 单列存储多值

7.4.3 单独表

7.5 值对象案例

7.5 .1 商品及价格策略

7.5 .2 商品与评论

7.5 .3 订单与收货地址

7.5 .4 账本与流水

7.5 .5 角色与权限

7.6 额外的礼物———领域模型基础类库

7.6 .1 领域模型基类

7.6 .2 领域模型验证能力

总 结

第8 章 独立自主———聚合(Aggregate)

8.1 认识聚合

8.1 .1 使用聚合的原因

8.1 .2 聚合示例

8.2 聚合的规模

8.2.1 事务规模

8.2.2 业务一致性范围

8.2.3 通用语言参考

8.3 聚合的特征

8.3 .1 形成工作单元

8.3 .2 有唯一对外面

8.3 .3 知识聚合

8.3 .4 基本事务单元

8.3 .5 不可分割

8.3 .6 通过标识符集成

8.4 聚合的事务处理

8.4.1 全局事务

8.4.2 分布式事务

5微服务下的领域驱动设计

8.5 额外的礼物———简单Saga 实现

8.5 .1 编排式Saga 设计思想

8.5 .2 代码实现

总 结

第9 章 化土为玉———工厂(Factory)

9 .1 使用工厂的时机

9 .2 工厂的责任

9 .2.1 简化构建领域模型

9 .2.2 保障对象合法

9 .2.3 明确对象责任

9 .2.4 避免知识垄断

9 .3 工厂的实现形式

9 .3 .1 领域模型包含工厂方法

9 .3 .2 聚合子类作为工厂

9 .3 .3 领域服务作为工厂

9 .4 工厂实践

9 .5 使用工厂的注意事项

9 .5 .1 厘清使用约束

9 .5 .2 约束失败处理方式

9 .5 .3 注意替代方案

9 .5 .4 明确构建目标

9 .5 .5 不处理业务

9 .5 .6 保持简单

总 结

第10 章 浴火重生———资源库 (Repository)

10.1 认识资源库

10.2 资源库的设计

10.2.1 接口与实现分开

10.2.2 考虑输入输出限制

10.2.3 明确使用目的

10.2.4 不包含业务

10.2.5 屏蔽持久化

10.2.6 依据业务定义

10.2.7 保持简单

10.3 资源库实现

10.4 如何处理层级关系

10.5 使用资源库时的注意事项

10.5 .1 数据级联

10.5 .2 多种持久化方式共存

10.5 .3 性能处理

10.6 额外的礼物———工作单元(Unit of Work)

10.6 .1 如何使用本地事务

10.6 .2 工作单元简介

10.6 .3 工作单元的实现

总 结

第11 章 运筹帷幄———领域服务(Domain Service)

11 .1 认识领域服务

11 .1 .1 订单实体担负的责任过重

11 .1 .2 代码不够规范

11 .2 领域服务的作用

11 .2.1 执行业务逻辑

11 .2.2 对象转换

11 .2.3 处理对象协作

11 .2.4 减少对象耦合

11 .2.5 控制业务走向

11 .3 领域服务的使用模式

11 .3 .1 实体引用领域服务

11 .3 .2 嵌套使用领域服务

11 .3 .3 应用服务引用领域服务

11 .4 领域服务的特性

11 .4.1 无状态

11 .4.2 参数多为实体

11 .4.3 只依赖领域模型

11 .4.4 反映通用语言

11 .4.5 承担业务指挥

11 .4.6 返回值有限制

11 .5 额外的礼物———微服务中的面向对象编程

11 .5 .1 如何进行分布式环境下的面向对象编程

11 .5 .2 对领域服务的反思

总 结

7微服务下的领域驱动设计

第12 章 承前启后———应用服务(Application Service)

12.1 认识应用服务

12.1 .1 应用服务对命令型业务的支撑

12.1 .2 应用服务对查询型业务的支撑

12.1 .3 宏观上的应用服务

12.2 应用服务的使用限制

12.2.1 关注输入限制类型

12.2.2 遵守输出类型约束

12.2.3 使用依赖注入

12.2.4 无需接口

12.2.5 参数必验

12.2.6 依据业务进行命名

12.2.7 关注异常处理

12.3 额外的礼物———应用服务接口参数验证

总 结

致 谢

参考文献