事件存储是什么意思

事件存储：存储所有聚合根里面发生过的事件。 1.事件存储中可以做并发的处理，比如Command 重复，领域事件的重复 2.领域事件的重复通过聚合根Id+版本号判断，可以在数据库中建立联合唯一索引，在存储事件时检测重复，记录重复的事件，根据业务做处理 3.这里要保证存储事件与发布领域事件的一致性 如何保证存储事件与发布领域事件的一致性 先存储事件然后在发布领域事件，如果发生异常，就一直重试，一直到成功为止，也可以做一定的处理，比如重试到一定的次数，就通知，进行人工处理 我选择了CAP + Policy + Dapper 事件溯源：在事件存储中记录导致状态变化的一系列领域事件。通过持久化记录改变状态的事件，通过重新播放获得状态改变的历史。 事件回放可以返回系统到任何状态 聚合快照：聚合的生命周期各有长短，有的聚合里面有大量的事件，事件越多加载事件以及重建聚合的执行效率就会越来越低，快照里面存储的是聚合 1.定时存储整个聚合根：使用定时器每隔一段时间就存储聚合到快照表中 2.定量存储整个聚合根：根据事件存储中的数量来存储聚合到快照表中事件溯源的实现方式 1.首先我们需要实现聚合In Memory， 2.在CommandHandler中订阅 Command命令， 创建聚合时 ，在内存中维护一个数据字典，key为：聚合根的Id，value为：聚合 修改，删除，聚合时，根据聚合根的Id，查询出聚合 如果内存中聚合不存在时：根据聚合根的Id 从聚合快照表中查询出聚合，然后根据聚合快照存储的时间，聚合根Id，查询事件存储中的所有事件，然后回放事件，得到聚合最终的状态。

在领域驱动里面，infrastructure作为基础设施，是提供技术细节的模块。需要强调的是，很多人会误以为infrastructure就是传统的DAO层，其实infrastructure包括但不限于DAO层，比如文件处理，三方调用，使用缓存，发送异步消息等具体的技术细节实现都存在于infrastructure层。那么技术细节是什么呢。在我们看来，技术细节包含以下特征

案例1：我们的实体需要持久化（存储），所以我们需要提供存储的实现。领域层的repository.save等方法提供了持久化接口约定，对于infrastructure来说，如何实现这个方法的代码，就是技术细节。那么我们如何实现这个过程呢？自然是选择缓存，OSS存或者数据库存。如果选择数据库，则进而需要选择orm框架，配置...，实现repository.save的接口，这些都属于持久化所需的技术细节代码。

案例2：我们的应用需要导出资产包相关的excel形式数据，那么当导出资产包数据时，文件领域模块提供了导出的统一接口，资产领域模块提供了资产包的适配接口，而导出excel的代码需要使用easyExcel或者POI等第三方框架，属于技术细节代码。

案例3: 接案例2，为了实现导出时所需的excel排版格式，排版本身的格式与业务有关，比如在我们的业务场景下，我们导出调解明细（我们项目特定的一个领域模型）的时候，只需要按照常见的导出方式即可，而导出资产明细（我们项目特定的一个领域模型）则需要解析拼接所有的动态数据列，合并显示每条数据不同的动态列，而这一切是由业务决定的。根据业务不同有不同的排版要求这一点体现了资产域需要提供文件域的导出策略，调解域也需要实现文件域的导出策略。这些都属于描述业务信息的约定，而这些约定的具体实现比如怎么把实体的那一个属性映射到excel的哪一行哪一列，则属于技术细节。这种区分方式显性化了业务的概念，同时又将实现放在了基础设施层，提供了一定的解耦性。

说完了infrastructure的技术细节的定义，我们接下来聊几个在采用DDD研发模式下，infrastructure层开发过程中经常会遇到的一些问题及我们的解决方案。

为了让业务逻辑和代码实现解耦，在repository的约定中，我们通常用“save保存”代替我们通常说的“insert（插入）“，”update（更新）”这样的技术术语，以屏蔽技术细节。这样带来的一个副作用是，在save时就需要根据策略判断调用insert还是update，我们使用的策略是根据id是否是空决定，即我们所有的实体对象都有一个属性，类型为Id类的子类，id对象的属性（数据库里面实际存放的id值）可能为null，但是id对象，本身不会为null，根据这个对象可以判断当前实体id是否为空。

对于聚合场景，子实体是需要知道聚合根的id的，因为在存储到数据库时可能需要以外键的方式存储对象间的映射关系。

然而，在具体实现中，我们认为，实体之间的对象关系才是标识两个实体之间关系的方式，而不是id，所以生成实体时，先通过对象引用关联对象，表明聚合和实体之间的关系，在保存到数据库的时候，通过实体生成数据库映射类的时候就可以知道当前数据的id是否为空，同时又能知道当前数据之间的关系。

对象之间的关系在1:1聚合保存的时候可能体现不明显，但是当1:N或者N:N批量保存聚合的时候，作用就比较明显了。在我们的系统中发起调解业务就需要批量保存调解批次。代码如下（欢迎吐槽，拥抱进步）

通过这种方式就解决了批量插入不能返回id，同时又能继续复用id.isNew()判断是否为新数据的方式（这里我们没有创建entity基类，所以判断放在了Id上）。

以上方法提供了批量保存时如何区分是新增还是更新。下面我们来谈谈我们项目内提供的插入和更新模板代码。

对于领域来说，save是基本的保存代码。方法传入的参数往往是一个存在于内存中的聚合根对象，有时包含全量的子实体，VO和全量的字段，而在插入场景，对批量请求我们希望支持批量插入，减少对数据库的IO频率，在更新场景下，我们希望减少update时的更新字段的数量（只更新需要更新的字段），这有助于减少数据库IO次数、binlog大小和mysql数据库索引变更带来的开销，所以是非常有必要的。因此对于infrastructure来说，可以提供统一的定制化模板方便repository定制化更新字段的方法快速实现。

由于我们的系统使用的是mybatisplus的ORM方案，所以我们根据api和mysql的批量语句开关提供了一个批量插入和批量更新的Mapper基类，其中insertBatchSomColumn是mybatisplus自带的，updateBatchById则是我们实现的，文档链接如下https://mp.toutiao.com/profile_v4/graphic/preview?pgc_id=7062223527654916621通过这种方式可以轻松地提供定制化更新某几列的sql，减轻sql编写负担。

这一次要讲的其实就是上面提到过的excel导入导出的案例。对于我们的系统来说，具有资产域，文件域，调解域等。其中资产域、调节域等三个域需要导入导出excel。但是我们在设计的时候认为文件的 *** 作属于文件域的概念，所以应当由文件的domain提供功能。但是很明显，具体的导入导出的策略根据数据的不同是可以变化的。所以针对这种情况，我们回归到领域驱动的实现的本质------面向对象技术来思考这个问题的优雅解法。以导入为例

代码如下

上面4份代码是domain的，最下面的是infrastructure的，这里我们只讲infrastructure的（但是我个人认为领域分层后还是需要整体考虑的，所以才会贴上domain的代码）。

这是我们对于跨域业务逻辑的处理办法。

为了保证各领域模型间的解耦，我们经常通过最轻量级的领域事件的方式实现，而不是类似metaq，msgbroker这样的异步分布式消息中间件。领域事件的发送有很多的实现方案，我们倾向于直接使用spring的功能，因为我们需要同步保证事务。但是spring的event发送需要继承ApplicationEvent而领域事件我们又希望独立于spring的event体系，所以我们通过对spring的了解发现了spring已经提供了 PayloadApplicationEvent 可以实现这种功能实现上和其他的spring的event一致，获取我们自己定义的event的方法如下

这里的getPayload()可以获取到我们放进去的领域事件TimeoutEvent

在任何系统中都会有批处理的业务。可能是批处理聚合，可能是批处理聚合内的实体类。这里说一下我之前遇到的一个帖子（jdon）上的讨论。帖子上说的是有一个排班业务，一条班表数据作为聚合存在着每日排班子实体，每日排班下又存在着排班明细子实体，当日期逐渐增加时一条排班需要加载好几年的数据用于生成聚合，而实际上则仅仅只需要计算最近几周的数据。这里存在两点问题

第一点自然不用多说，技术实现以提供业务功能为核心是我一直以来的主张。所以当数据量可能会不断增大的情况下不用加载完整自然是必须的（哪怕内存存储的下也应当尽可能少的消耗）。第二点来说帖子的一位回复者倾向于DomainService提供专门的适配方法，用于加载几周的数据。

我们的系统中存在一个有一些类似的业务。我们的系统需要每隔几分钟就运行一次批处理任务，获取所有已经过期的调解明细，并且设置为过期。调解明细属于调解批次的聚合，所以我们有同样的需求。

我们在此提供一种我们的实现，供参考。

repository的实现根据面向对象原则，仅仅提供如何查询过滤数据库数据

迭代器的实现提供了迭代职责实现

至此实现了批处理加载聚合的逻辑，同时可以提供聚合的部分加载（需要注意业务的正确性不会因为聚合的不完全加载而产生问题）。

最后总结一下

---