SOA是以服务这个方式对外提供功能，我们很显然喜欢在Service中加上JTA等事务，比如EJB的无态Bean或Spring的@Transaction标注都是激活这样的功能，这种方式实际是一种悲观事务，容易引起死锁，特别是在高并发情况下。

我们需要重新思考的是：将事务加在服务这样处理过程上，这个思路是不是有问题？因为服务只是对外提供一个统一接口，不代表对内其就是一个统一的处理过程，是一个process，这是很多人对服务的误解之处。

新的EDA+reactor思路是：服务通过发送消息给一个聚合根实体，也就是Actors模型，聚合根实体是通过消息与外面交互，其内部状态一致性操作由其自己完成。

准确说，DDD+ CQRS +EDA+reactor + Actor才是高并发事务SOA的终极解决方案。

参考：http://www.jdon.com/45738

[该贴被banq于2013-09-17 11:38修改过]

这种架构虽然提高了吞吐量，但是只能做到最终一致性。如果要求强一致性，在遇到一次修改涉及多个聚合根的时候，就需要事务了。上次你提到的关于利用事件的方式来实现转账的方法（有一个帖子）实际上也没有做到转账的强一致性。

你可能还没有理解我之前“数据喂机器”的理论，你这段话的逻辑实际上将聚合根和事务过程并列了，或者说，认为事务不属于聚合根范畴，甚至是凌驾于聚合根之上，这其实是“数据喂机器”导致。

实际上，高一致性事务等同于逻辑一致性，是被聚合根(也就是Actors模型)管理的，属于聚合根的上下文边界的。如果你不习惯这样的思维，那么我们可以说，凡是你认为需要使用高一致性强事务的地方就是一个有界的上下文，可以用聚合来表达。

不要将聚合根实体看成没有行为守护的抽象数据类型，看成被动的数据，聚合根是有强一致性保证的富对象。

http://www.jdon.com/45736

[该贴被banq于2013-09-18 09:17修改过]

意思是，只要是需要强一致性的地方都应该由聚合根来实现？那银行转账呢？你不是跨聚合根要实现强一致性吗？你上次翻译的通过设计一个转账聚合根来在代码层面实现2pc的方法，本质上也没有实现强一致性。因为当转账聚合根在第二阶段要求源账号和目标账号分别去扣钱和加钱时，这两个操作的扣钱和加钱动作并不是在一个事务内，也就是不是同时发生。详见我之前对那个帖子的回复。