DDD系列：三、Repository模式

BigBug_500

已于 2023-05-07 15:39:59 修改

阅读量2.2k

点赞数 1

分类专栏： # DDD 文章标签： java

于 2023-04-30 11:50:01 首次发布

转载/复制请联系作者:[email protected]

本文链接：https://blog.csdn.net/bigbug_500/article/details/129827770

版权

DDD 专栏收录该内容

7 篇文章 1 订阅

订阅专栏

为什么需要Repository？

Anemic Domain Model（贫血领域模型）特征：

有大量的XxxDO对象：这里DO虽然有时候代表了Domain Object，但实际上仅仅是数据库表结构的映射，里面没有包含（或包含了很少的）业务逻辑；
服务和Controller里有大量的业务逻辑：比如校验逻辑、计算逻辑、格式转化逻辑、对象关系逻辑、数据存储逻辑等；
大量的Utils工具类等。

Anemic Domain Model的缺陷：

无法保护模型对象的完整性和一致性：因为对象的所有属性都是公开的，只能由调用方来维护模型的一致性，而这个是没有保障的；之前曾经出现的案例就是调用方没有能维护模型数据的一致性，导致脏数据使用时出现bug，这一类的bug还特别隐蔽，很难排查到。
对象操作的可发现性极差： 单纯从对象的属性上很难看出来都有哪些业务逻辑，什么时候可以被调用，以及可以赋值的边界是什么；比如说，Long类型的值是否可以是0或者负数？
代码逻辑容易重复： 比如校验逻辑、计算逻辑，都很容易出现在多个服务、多个代码块里，提升维护成本和bug出现的概率；一类常见的bug就是当贫血模型变更后，校验逻辑由于出现在多个地方，没有能跟着变，导致校验失败或失效。
代码的健壮性差：比如一个数据模型的变化可能导致从上到下的所有代码的变更。

充血模型中，需要严格区分的两个模型：

数据模型（Data Model）：指业务数据该如何持久化，以及数据之间的关系，也就是传统的ER模型。只属于Infrastructure Layer
业务模型/领域模型（Domain Model）：指业务逻辑中，相关联的数据该如何联动。只属于Domain Layer

链接了这两层的关键对象，就是Repository。

Repository的价值

在传统的数据库驱动开发中，我们会对数据库操作做一个封装，一般叫做Data Access Object（DAO）。DAO的核心价值是封装了拼接SQL、维护数据库连接、事务等琐碎的底层逻辑，让业务开发可以专注于写代码。但是在本质上，DAO的操作还是数据库操作，DAO的某个方法还是在直接操作数据库和数据模型，只是少写了部分代码。

所以，Repository 的价值是：

向内层，屏蔽存储相关的逻辑：
- 业务逻辑（DomianService）和 DB相关的操作（DAO、DB）隔离开，业务逻辑中不关心数据存储形式和技术
向外层，屏蔽业务变化
- 业务迭代时，如果不调整DB字段，仓储层不变化。

模型对象代码规范

模型类型：

3种模型的区别，Entity、Data Object (DO)和Data Transfer Object (DTO)：

DO（数据对象）

在DDD的规范里，DO应该仅仅作为数据库物理表格的映射，不能参与到业务逻辑中。为了简单明了，DO的字段类型和名称应该和DB中的字段类型和名称一一对应。（当然，实际上也没必要一摸一样，只要你在Mapper那一层做到字段映射）
Entity（实体对象）

实体对象是我们正常业务应该用的业务模型，它的字段和方法应该和业务语言保持一致，和持久化方式无关。也就是说，Entity 和 DO 很可能有着完全不一样的字段命名和字段类型，甚至嵌套关系。Entity的生命周期应该仅存在于内存中，不需要可序列化和可持久化。
DTO（传输对象）：

主要作为Application Layer 的入参和出参，比如CQRS里的Command、Query、Event，以及Request、Response等都属于DTO的范畴。DTO的价值在于适配不同的业务场景的入参和出参，避免让业务对象变成一个万能大对象。该对象需要序列化，其余两模型都不能实现序列化接口。

模型对象间的关系：

复杂的Entity拆分多个DO对象
多个关联的 Entity 合并一个 DO
从复杂 Entity 里抽取部分信息形成一个 DTO 列表
从多个 Entity 中提取信息，输出一个 DTO

模型转化器

请添加图片描述

DTO Assembler：

在 Application 层，Entity 与 DTO 之间的转化器有一个标准的名称叫DTO Assembler，他的核心作用就是将1个或多个相关联的Entity转化为1个或多个DTO。

Data Converter：

在Infrastructure层，Entity 与 DO 的转化器没有一个标准名称，但是为了区分 Data Mapper（Mybatis的Mapper），我们叫这种转化器Data Converter。

带来的好处：

通过抽象出一个 Assembler/Converter 对象，把复杂的转化逻辑都收敛到一个对象中，并且可以很好的进行单元测试。

带来的问题：

当业务复杂时，手写 Assembler/Converter 是一件耗时且容易出bug的事情，所以业界会有多种Bean Mapping的解决方案，从本质上分为动态和静态映射。
- 动态映射根据反射动态赋值，大量的反射调用，将带来性能问题。
- 推荐使用 MapStruct（MapStruct官网），该组件通过注解，在编译时静态生成映射代码，其最终编译出来的代码和手写的代码在性能上完全一致，且有强大的注解等能力。
从使用复杂度角度来看，区分了DO、Entity、DTO带来了代码量的膨胀（从1个变成了3+2+N个）。但是在实际复杂业务场景下，通过功能来区分模型带来的价值是功能性的单一和可测试、可预期，最终反而是逻辑复杂性的降低。

Repository代码规范

Repository 出现的目的，是为了将 业务逻辑（软件）与硬件（DB、Cache、文件系统等）和固件（与硬件强关联的软件）完全隔离开。所以为了体现出软件的特点，Repository 中需要注意以下三点：

接口名称不应该使用底层实现的语法： 常见的insert、select、update、delete都属于SQL语法，使用这几个词相当于和DB底层实现做了绑定，在 Repository 为了区分开，我们使用语法如find、save（insert或update）、remove。
出参入参不应该使用底层数据格式： Repository 操作的是 Entity 对象（实际上应该是Aggregate Root），不应该直接操作 DO。Repository 接口存在于 Domain 层，实现类建议在 Infrastructure 层。
应该避免所谓的“通用”Repository模式： 很多ORM框架都提供一个“通用”的Repository接口，然后框架通过注解自动实现接口，比较典型的例子是Spring Data、Entity Framework等，这种框架的好处是在简单场景下很容易通过配置实现，但是坏处是基本上无扩展的可能性（比如加定制缓存逻辑），在未来有可能还是会被推翻重做。当然，这里避免通用不代表不能有基础接口和通用的帮助类。

复杂Aggregate的save

在对一个复杂Aggregate（包含多个Entity）的 save 操作中，并不是所有 Aggregate 里的 Entity 都需要变更。

如果不知道 Aggregate 中的变更有哪些，那么只有全量更新，导致大量的无用DB操作；如果我们可以追踪到变更的 Entity，那么将可以减少很多无用的 DB 操作。

业界目前有两个主流的变更追踪方案：

基于Snapshot的方案：当数据从DB里取出来后，在内存中保存一份snapshot，然后在数据写入时和snapshot比较。常见的实现如Hibernate
基于Proxy的方案：当数据从DB里取出来后，通过weaving的方式将所有setter都增加一个切面来判断setter是否被调用以及值是否变更，如果变更则标记为Dirty。在保存时根据Dirty判断是否需要更新。常见的实现如Entity Framework。

方案对比：

	Snapshot（推荐）	Proxy
复杂程度	通过cache实现，使用流程较简单	通过代理标记实现，工具类较复杂，使用流程简单
内存消耗	高	无额外内存占用
带来的问题	cache与DB的数据一致性问题	代理标记Dirty时，对复杂Aggregate的判断问题

Repository的迁移流程

使用 Repository 模式最大的收益就是可以彻底和底层固件解耦，让上层业务可以快速自发展。

假设传统方式下，查询数据只有如下两个类：

OrderDO：和DB一样的数据结构
OrderDAO：和DB交互的业务操作类

其升级流程如下：

生成Order实体类，初期字段可以和OrderDO保持一致
生成OrderDataConverter，通过MapStruct（Java Bean转换器）基本上2行代码就能完成
写单元测试，确保Order和OrderDO之间的转化100%正确
生成OrderRepository接口和实现，通过单测确保OrderRepository的正确性
将原有代码里使用了OrderDO的地方改为Order
将原有代码里使用了OrderDAO的地方都改为用OrderRepository
通过单测确保业务逻辑的一致性。

CQRS 和 EventSourcing 模式

什么是CQRS模式？

CQRS是 Command and Query Responsibility Segregation 的缩写，直译是命令与查询责任分离的意思。

这里涉及到两个定义，何为命令？何为查询？

命令会改变对象的状态，但不返回任何数据。
查询会返回数据，但并不改变对象的状态。

如果将查询和命令简化理解成对数据的读写操作， CQRS模式的含义就是，应用架构中负责模型读写的模块应当分离。这里的分离，不单是程序代码或逻辑上的分离，也包括数据模型，甚至是数据存储的分离。 CQRS Journey的这张图描述了 CQRS 的一种典型应用：
在这里插入图片描述
CQRS模式的优势：

CQRS 模式通常与 DDD 同时使用，但它不是一种全局性的架构模式，它只适用于特定的bounded context，对于领域模型十分复杂的场景，CQRS模式可以增强架构的扩展性和灵活性，同时降低模块的复杂度。由于读和写的模型分离，可以分别针对读写操作优化，同时避免的数据锁定，对于性能提升也有帮助。

CQRS的缺点：

实现架构复杂：
- 它并不是一种易于实现的模式。因为读写责任的分离，它不如 CRUD 来的直观。而且读写数据同步和确保数据一致性会是一个问题。比较常见的作法，是通过事件(Event)来将写操作的结果同步到读操作的数据库中。
数据一致性问题：
- 为了确保数据的一致性，常常借用Event Sourcing模式来实现事件的存储和分发。同时由于通过事件实现的数据同步，其实是异步完成的，在分布式系统中，需要考虑数据的最终一致性(Eventual Consistency)。在CQRS模式中，通常写数据具有完全一致性(Full Consistency)，而读数据则具有最终一致性。

这些局限决定了，CQRS模式并非适用于所有场景。它通常只适用于复杂多变，涉及多方操作的场景。而对于业务简单，使用CQRS模式可能会增加开销，但并不能带来明显的好处。使用 CQRS等模式是为了帮我们解决问题，而不是在简单问题上强制某种规范来限制我们。

什么是 Event Sourcing 模式？

Event Sourcing (ES)模式是一个关于如何存储domain model状态的模式。这个模式不直接存储模型的状态，而是存储模型状态变化的历史。应用想要获取模型的当前状态时，需要重演整个历史来得到当前状态。一个常用的解释ES模式的场景，是银行账户。

账户余额的直观存储方式，是存储余额本身。当用户存入100元时，余额假定是100，其后用户取出10元，余额变为90，其后用户又存入50元，余额变为140。当用户查询余额时，系统直接获取当前余额。

同样的场景，使用 ES 模式时，系统不存储余额本身，而是存储用户的行为，即Event。当用户存入100元时，存储“存入100”这个Event，当用户取出10元时，存储“取出10”。当用户查询余额时，系统获得所有的Event，然后进行计算，得到余额。这实际上是金融机构存储交易信息的方式。Bitcoin 也是使用同样的方式存储账户的 send 和 receive 操作，并且将所有的Event使用 blockchain 链接起来。

EventSourcing的优势：
1.简化写操作：

所有Event一旦发生，就变为 immutable，写操作就变为简单的添加纪录，避免了复杂的锁定和冲突。
同时ES模式保留了所有状态的历史，容易做 audit，或纠错。

EventSourcing的缺点：

历史数据的增加，查询操作的性能可能会降低。

通常 CQRS 模式和 ES 模式会被同时使用。因为通常CQRS模式使用 Event 来同步读写两端的数据，使用ES模式存储Event有助于这种数据同步，在数据出现不一致的情况时（根据CAP理论，这在分布式系统中是不可避免的），读操作端可以通过 replay event 的历史，来确保数据的最终一致性。