# event-sourcing

**Repository Path**: dsfsfs/event-sourcing

## Basic Information

- **Project Name**: event-sourcing
- **Description**: 事件溯源
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2021-09-16
- **Last Updated**: 2022-11-24

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

可追溯的事件
---
传统的系统只会存储当前状态的信息，而过往的信息会随着新的操作变化，曾经的信息将会被新的信息覆盖，不留痕迹。 
而当我们需要追溯信息是如变化成当前的状态的时候，我们只能根据当前的实现逻辑来进来推断。
若是逻辑信息的变化经过几十个步骤，甚至是几百个步骤时，只根据当前状态和查看代码实现是很难追溯的。

对此，很多系统在设计时，会将关键操作的结果记录下来，以便查阅。比如，供应链系统中采购、生产加工、销售、出入库时都会采购单
生产/加工工单、销售单、出库/入库单等单据作为重要的凭证被记录下来。而更细的，采购单之前还会有采购请购单什么，以记录生成采购单之前的操作信息。
这些被记录下来的信息对于系统的用户开展业务来说至关重要，所以系统是必须要记录的。但也有一些操作记录是用户不关心，但出现问题需要追溯时才关注的。
而这些记录可能正好没有在系统数据库留下痕迹，此时开发人员可能只能查看系统日志，从一堆杂乱的信息中追查我们想看到的信息。

而对于这种情况，“事件溯源”将聚合以一系列事件的方式进行持久化保存，从而可以通过事件来追溯查找聚合历史状态的优点，可以提供给我们一种新的查找问题的思路和方式。

事件溯源以事件为视角，来记录聚合当时的状态。这里的聚合是DDD中的概念，可以简单理解为：一个对象或多个对象的概念集合体。
而在《实现领域驱动设计》、《微服务架构设计模式》等书籍中介绍的事件溯源是基于CQRS架构来实现的，从目前我看到的介绍事件溯源的文章都是如此。
但这个CQRS架构的实现与我们传统的开发思路有太大差异，很多团队大概不会轻易的去尝试。

如果只是为了更方便追溯历史信息，而不想实现复杂的CQRS架构，其实也是可以办到的。这也是此项目要达到的一个目的。

此项目将提供一系列客户端工具，方便使用者像调用日志接口一样主动的在关键事件点去记录聚合的状态信息。客户端工具将会把聚合信息发送到消息队列中，便于服务端接收并存储到数据库中。
而数据库将会用NoSQL（MongoDB、ElasticSearch），以提供更强大的查询功能和数据分析的能力。
该项目还提供了基本的查询功能，通过基本查询、高级查询等查询条件来查找以时间维度排列的事件信息和每个事件当下的聚合信息，来解决我们的问题。