一直隐身看jdon的东东，很有感触，在此十分感谢 bang
疑问：
比如某个Domain对象会有自己的一个operation从而引发一个event 单事件 可以保证事务性。
如果是某个service 要用到两个Domain对象并进行相关的operation，此时如何做到多个operation的事务性。
就拿 银行转帐的例子来说
两个Account都会有自己的operation，而在转账的service中要触发每个Account的相关operation，而每个
Account都有自己的event产生，这时如何保证多个operation的事务性呢？
[该贴被admin于2011-11-03 19:41修改过]
Event Sourcing实现事务的方式是先持久后回放，将这个operation涉及的事件都持久化append到日志或数据库中，当其中一个Event失败，重新开始播放这个事件，可以设置Try几次，如果还不行通知管理员，这类似JMS的消息事务机制。
每个Domain的event都是分别独立分发，这如何标识某些operation是处于一个事物中的呢， 难道要在相关的event里都分配一个flag么？ 如果是这样的话，看上去有点别扭啊。
是否可以在这些operation之外再加一层----标识事务性
eventList{A_event,B_event} 如此来表明 两个operation是处于一个事务
主要是对传统事务的认识要改变，传统事务提出ACID，是因为这个思路假设operation内部都不是原子性等；而当前使用事件消息，本身是原子性的。
所以，如果哪个事件出错，只要回滚重放这个事件即可，与外面的operation无关。
还有一种做法是利用传统JTA+有事务机制的JMS或MQ：将这些Domain Event发到JMS的Queue中，在Queue的Consumer端完成带有Operation业务的操作，在这个operation方法中，不断读取Queue的Events，当然这个Queue一定是与operation方法方法对应，事先在JMS服务器中已经配置好；Consumer这个operation方法中使用传统的JTA事务，这样这个JTA事务将确保operation方法事务性，要么全部完成，如果有一个事件处理出错，整个全部回滚，Queue本来被读取的全部事件消息还留在Queue中，等待Consumer下一次重新执行。
我觉得对于多事件同一事务的情况，是一种类似工作流思维，是一个整体。若用不变性来处理，可以认为，前面任何一个事件都没有发生改变实体状态的操作，只是单单把计算结果交给下一个事件（击鼓传花？想到某个模式了- -），最后只在最后一个事件改变状态。
to bang
确实是受到传统事物的影响，毕竟这种方式以用多年，不太好转变
再假设:
某个Domain的operation是事物的，原子的。而现在又有了新的service，这个仅仅需要某几个Domain的operation组合即可。此时怎么处理呢？
这就好像spring的那个事物嵌套一样。
个人观点：
某个operation或者service(包括多个operation且每个operation都是原子的)，我们只需要在send event之前再将这些operation再包裹一层“事物”的“壳”即可.
to SpeedVan
多事件处于同一事务，但不一定就是“击鼓传花”，而有可能是某些Domain要根据“花”来operation，这些operation被要求是事务的，原子的。
再补充下，我不是和bang，SpeedVan 拧巴。也许思维上自己正跟自己拧巴呢。
事务嵌套或化分边界，是因为整个应用系统有事务和非事务之分，如果整个应用系统都是原子的，那么就没有这种事务边界了。
所以，整个应用都是由一系列Event组成的，整个应用本身是原子组成的，如果要划分事务边界的话，整个应用就是一个大的事务。
相关讨论：
当eventSourceing遇到并发和事务将变得复杂
最终一致性在现实世界中到处存在
[该贴被banq于2011-11-10 07:34修改过]