jdon framework 为什么没有用Event Source 呢
没有发现Event Store /snapshort 之类的东东，还是没必要用
jdonframework已经提供了事件机制，符合Event Source一部分定义，只是有关事件持久化event store没有在框架里实现，因为取决于使用nosql还是文件系统。
jdonframework定位在业务层的框架，持久层目前没有涉及，其实event store实现起来还是非常方便，在一个CQRS系统中，一台服务器专门复杂模型管理，一个专门负责查询。在模型管理的服务器中创建一个jdonframework的事件监听者，将事件append到文件或nosql中，然后启动定期job，将每天或每小时新增的事件数据复制到负责查询的服务器上，再次执行，这样可以同步两台服务器之间数据库。
主要是考虑如果多个Event组成一个完整的业务过程，如果有Event失败，那么整个业务完整性可能没法保证，如果有Event Store/snapshot机制的话，就不必担心了。
另外问下agregate(聚合根)有必要使用吗，和普通domain对象有什么区别，关注点是什么？ 和Context（场景）的定位有什么不同？
还有事件的多个消费者（Handler）有没有必要考虑先后顺序？在看disruptor例子中有发现拼接消费者依赖
谢谢bang兄回复
聚合根是一种领域对象，领域对象不只是一个对象，有可能是对象群，那么就需要聚合根。
Context驱动开发很热门，在一个场景下，既有符合这个场景上下文的领域实体，也有相关行为，场景下的动词和名词都不能少，动词是事件行为，名词代表状态。
多个消费者如果需要顺序，实际也是可以方便自己实现的，在内存中做给类似事务机制中的监测的状态，监督每一步的完成。
如果想实现生产者和消费者之间的事务，那么引入JMS是一个方案：
事件生产者--->JdonFramework/Disruptor --->事件消费者/JMS的生产者--->JMS--->JMS的消费者。
因为第一个生产者和消费者之间是通过多线程完成，可靠性很高，如果你不信任就如同不信任多线程一样，关键是事件的消费者的任务不呢繁重，因为承担消费者也是一个线程，如果这个过程复杂，可靠性比较低，那么这时依靠JMS对消息生产者和消费者的强事务关系保证。
JMS事务的大概原理是：如果JMS的所有消费者在执行任务时出错，那么所有消费者都回滚，其他消费者如同没有接受处理这个消息一样，消息依然留在JMS服务器中，等待下次重试，规定重试次数失败后报错，但是消息依然留在JMS那里。
1.这么说，你可以把聚合根领域对象，来做DCI，像普通领域对象一样，可以吧。
2.多个消费者，在jdonframework中，是不是可以在@Consumer中增加优先级或order之类的东西，给排个序,放在disruptor中，可以disruptor.addHandler(A).then(B)
3、也就是根据不同情况采取不同的技术。
能不能这么做呢，
class DomainServie{
myService(){
beginTransaction
DomainObjectA.SendDomainMessage();//每个Message都经过disruptor被Consumer处理
DomainObjectB.SendDomainMessage();
endTransaction
}
}
这么做有什么不妥吗
1.从DCI或BDD角度来看，实体聚合根是一种普通领域对象。
2.在jdonframework中，标注以@Consumer的A/B/C/D类是以类名字符串排序加入disruptor的。
3.在JdonFramework/Disruptor编程模型下，相当于换了一种新语言，缺省是并发编程模型，而beginTransaction前提是顺序编程，针对顺序编程通过事务监控锁来保证过程的一致性或者回滚。
所以，首先从并发回到顺序，而并发和顺序的唯一区别就是有无堵塞，回到顺序加入堵塞即可，为了实现这种顺序执行过程，我们使用Jdon框架的DomainMessage的中一种堵塞读取方法，将上一个事件的DomainMessage传递给下一个通知事件，然后在下一个事件激活后堵塞读取上一次事件结果DomainMessage。
如果想实现事务回滚，由于不能在多个事件@Consumer之间实现，因为违反并发基本架构，从设计角度看，需要事务回滚的代码实际凝聚性很强，完全可以放在一个@Consumer中执行，然后在这段上加上JTA事务即可。
弄明白了并发和顺序的问题，还有在Disruptor的Consumer中使用事务的想法也满不错的。谢谢banq的回答。