(第8天)每日源码调试之旅--实现CQRS模式的AXON框架

接着前一天的调试，断点来到eventsQueue中设置的PREPARE_COMMIT阶段的回调：

此阶段先判断UnitOfWork有没有parent和其parent是否在PREPARE_COMMIT之前的阶段，满足条件的话，将当前UnitOfWork的eventQueue加入到其parent的eventQueue里，此处没有parent直接进入doWithEvent方法:,进入前先处理参数，调用AbstractEventBus（实际是其子类EmbeddedEventStore）的intercept方法：

此处完成的操作是调用定义的EventMessage的拦截器进行拦截处理，完成后返回处理过后的EventMessage的List，随后进入doWithEvent方法：

此处直接调用传入AbstractEventStore（EventStore的抽象实现，使用一个EventStorageEngine来存储和加载events，实际是其子类EmbeddedEventStore）的prepareCommit回调：

此处先调用AbstractEventStorageEngine（处理事件序列化和上传的抽象EventStorage实现，实际是其子类JdbcEventStorageEngine）的appendEvents方法：

接着调用JdbcEventStorageEngine（使用JPA存储和获取事件的EventStorageEngine实现）的appendEvents方法：

此处实现的是利用XStreamSerializer来持久化event，处理完后结束所有appendEvents方法，回到prepareCommit回调，接着进入AbstractEventBus（实际是其子类EmbeddedEventStore）prepareCommit（给messageMonitor发信号，提示event到来，然后调用eventProcessors处理events）方法：

本demo未定义messageMonitor，直接进入消息处理过程，处理过程的内部实现与command的处理过程实现大致相同，不赘述，最终会调用到查询端定义的eventHandler方法：

此处操作是存储ProductEntry，同步命令端和查询端的product数据。完成存储后一路返回，回到prepareCommit方法，继续返回，回到PREPARE_COMMIT阶段的回调方法：

接下来是确保在发布准备提交阶段发布的事件也被发布，即预防在刚刚处理event时添加了新的event，导致没有发布，最后结束回调，重复之前的UnitOfWork的切换阶段操作，来的下一个阶段COMMIT的回调：

此阶段的回调中的doWithEvent方法传入的commit回调并未做任何操作，直接结束，但是这个阶段的onCommit回调的调用前触发了第二天调试中写到的SimpleCommandBus的doDispatch方法里的事务的提交，继续切换到下一个阶段AFTER_COMMIT，进入定义的回调方法中：

直接进入this::afterCommit回调：

进入EmbeddedEventStore中的EventProducer内部类的fetchIfWaiting方法：

此处操作不太了解，估计与之前保证对aggregate并发修改的悲观锁机制有关，等下次了解完并发机制后再来仔细调试这个框架设计的并发相关的源码，方法结束，返回到切换UnitOfWork的切换阶段操作，进入下一个阶段ClEANUP阶段的操作：

此处是从UnitOfWork的资源中移除了event，表明event已经处理完毕

最后切换到CLOSED阶段，此阶段为定义回调，直接结束，回到AbstractUnitOfWork（实际上是子类DefaultUnitOfWork）的commitAsRoot方法：

依然无剩余操作，继续结束方法回到AbstractUnitOfWork（实际上是子类DefaultUnitOfWork）的commit方法：

做清理操作，当前UnitOfWork移除DefaultUnitOfWork，即DefaultUnitOfWork关闭，回到最初的DefaultUnitOfWork的executeWithResult方法：

返回得到的结果，创建的product的id，继续返回，结束SimpleCommandBus的doDispatch(command, handler)方法，回到doDispatch(command, callback)方法：

剩下的方法都未定义回调或者未重写，为空操作，统统直接结束，一路返回，回到最初的源码入口：

至此，调试结束。下次做一下调试总结。