jdon framework 为什么没有用Event Source 呢

12-08-20 selayou
没有发现Event Store /snapshort 之类的东东,还是没必要用

19
banq
2012-08-21 07:51
jdonframework已经提供了事件机制,符合Event Source一部分定义,只是有关事件持久化event store没有在框架里实现,因为取决于使用nosql还是文件系统。

jdonframework定位在业务层的框架,持久层目前没有涉及,其实event store实现起来还是非常方便,在一个CQRS系统中,一台服务器专门复杂模型管理,一个专门负责查询。在模型管理的服务器中创建一个jdonframework的事件监听者,将事件append到文件或nosql中,然后启动定期job,将每天或每小时新增的事件数据复制到负责查询的服务器上,再次执行,这样可以同步两台服务器之间数据库。

selayou
2012-08-21 09:35
主要是考虑如果多个Event组成一个完整的业务过程,如果有Event失败,那么整个业务完整性可能没法保证,如果有Event Store/snapshot机制的话,就不必担心了。

另外问下agregate(聚合根)有必要使用吗,和普通domain对象有什么区别,关注点是什么? 和Context(场景)的定位有什么不同?

还有事件的多个消费者(Handler)有没有必要考虑先后顺序?在看disruptor例子中有发现拼接消费者依赖

谢谢bang兄回复

banq
2012-08-21 15:31
聚合根是一种领域对象,领域对象不只是一个对象,有可能是对象群,那么就需要聚合根。

Context驱动开发很热门,在一个场景下,既有符合这个场景上下文的领域实体,也有相关行为,场景下的动词和名词都不能少,动词是事件行为,名词代表状态。

多个消费者如果需要顺序,实际也是可以方便自己实现的,在内存中做给类似事务机制中的监测的状态,监督每一步的完成。

如果想实现生产者和消费者之间的事务,那么引入JMS是一个方案:

事件生产者--->JdonFramework/Disruptor --->事件消费者/JMS的生产者--->JMS--->JMS的消费者。

因为第一个生产者和消费者之间是通过多线程完成,可靠性很高,如果你不信任就如同不信任多线程一样,关键是事件的消费者的任务不呢繁重,因为承担消费者也是一个线程,如果这个过程复杂,可靠性比较低,那么这时依靠JMS对消息生产者和消费者的强事务关系保证。

JMS事务的大概原理是:如果JMS的所有消费者在执行任务时出错,那么所有消费者都回滚,其他消费者如同没有接受处理这个消息一样,消息依然留在JMS服务器中,等待下次重试,规定重试次数失败后报错,但是消息依然留在JMS那里。

selayou
2012-08-21 23:47
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

}

}

这么做有什么不妥吗

猜你喜欢
2Go 1 2 下一页