定义
聚合与事件源，称为A+ES，是通过事件来表示一个聚合的完整状态，这里的事件是自聚合创建以来的一系列变更事件。通过按照产生时的顺序重放这些事件，我们可以重建聚合的状态。
注意两点：一是全部的变更事件，包括创建事件，可以不依赖其它信息就可以重建聚合的完整状态；二是需要按产生时的顺序重放，也就是事件的表示需要有顺序标识，存储时也需要保存顺序，一般使用顺序的版本号来表示。
事件源的架构如下：
几个问题的答案
并发控制
事件都是有顺序版本号的，然后在插入新事件时，会把原版本号作为参数判断是否有新版本产生，类似乐观锁的CAS
如果有新版本产生，即冲突情况，可以加载新事件，然后重试插入事件
或实现一定的冲突决议，进行事件merge。不过这种方案是比较有难度的。
性能——大量事件流时
如果事件很多，比如一个聚合有百千级别事件时，如果有聚合操作，都要加载全部事件并重建聚合，那性能肯定有影响，可以有两种措施：
对事件流缓存，因为事件是不变的，或者是极少变化的，很好进行缓存
使用聚合快照，即预先把一个时间以前的事件重建好了持久化，然后在加载聚合实例时，只需要找到该聚合的最近一次快照和快照之后事件，就可以重建了
属性查询——读模型投射
使用A+ES的一个常见问题是如何通过属性来查询聚合。如果重建所有聚合实例，然后根据最终的聚合状态来过滤，那肯定是非常低效的。
这时候就应该使用读模型投射，即把事件都预先投射到聚合实例上，即预先重建好聚合状态，然后缓存起来，或持久化，然后有查询请求时直接在投射上执行查询就可以。其实这就是CQRS的思路。
工程实践
从上面论述，A+ES两个突出问题是重建性能和属性查询，而分别的解决方案是聚合快照和读模型投射，但在实际工程实践中，这样实现的系统还是比较复杂的，但直接使用RDB支持事务操作，所以聚合状态的修改会借助事务来保证强一致性，并满足属性查询需要，这基本可以满足一般的业务系统需求，如果有需要，会借助事件源的思路，把事件顺序持久化，用于事件追溯，问题查找，BI分析，状态校正或回滚，下面是架构图：
