为什么说服务无法被重用呢，我记得您以前的说过soa的服务是可以被重用的啊

SOA已经没有持久化这些低层次事情，见：数据库时代的终结，数据库持久化属于这篇PPT里面批判的两层架构UI+DataBase，后来有了现在三层架构SOA，SOA的多层架构比两层架构好处是，已经抛弃关注数据库或持久化概念，SOA已经让我们开始关注业务，谈论业务了，我们这里谈论的是：为客户提供连衣裙的订单服务。

每个子服务完成后向订单服务中心的缓存写入自己的状态，订单服务只要收集这些子服务的状态，如果每个子服务的状态都OK，订单就完成，可以向客户交付连衣裙了，如果有子服务的状态不OK，就无法交付。这里面没有什么回滚事务。如果需要追溯，只有EventSoucing提供的回放。

事务机制，回滚和高一致性这些都是IT专家鼓捣出来骗人的技术玩意，让我们偏离业务谈技术了，见这个帖子：弱一致性在现实世界中到处存在，这篇帖子批判了事务和同步，分布式事务带来的锁和性能是很差的，如果不用事务，用同步，在代码里要不断判断子服务失败怎么办等等。见：CAP原理和BASE思想

当然，我们通过逻辑分层让我们更关注订单服务这个业务，也不是说无需事先持久化，持久化被封装在子服务之中，以至于我们可以在更高层面只谈论业务，如下图逻辑分层：

[该贴被banq于2013-06-10 09:37修改过]

服务如果能按松耦合是可以重用的，但是实际上里面嵌入了大量面向过程代码，就无法重用了。

SOA的服务是一种粗粒度的功能提供，比如连衣裙订单服务，其中涉及很多步骤，如果你不使用包装封装这些小步骤变成一个个子服务，都扁平地写在订单服务中，如果有另外西装订单服务，就可能无法重用这些步骤，尽管流程上比较类似。

好了，如果你写成子服务了，如同本PPT讨论这样，有财务部门的子服务，有生产部门的子服务，你就是写成这样还是不行，可伸缩性扩展性还是有问题。

我们发展的层次是：
1. UI+DataBase的面向数据库，
2. 传统多层的SOA的脚步风格服务，没有子服务，服务中大量数据库存储操作。
3.DDD+SOA 也就是EDA+CQRS+SOA

深有同感，SOA本来目的是，服务自治，服务重用，但在实践过程中，和其目的有点背道而驰的感觉，及时可以重用，也不是那么优雅的重用，多数是一长窜参数，或者拷贝使用，个人认为这其实跟我们惯性思维习惯有很大关系，习惯这么做久而久之 即使出现了问题，也很难发觉。比如，两台机器间要发送数据client-server，大多数做法是client send to server 这么做是没有问题的，隐藏在背后的是两个机器之间发送耦合，如果client 和 server 之间以消息总线的形式，把消息交给 消息管理器去管理，那么client，server的耦合性，消息本身的管理，都将得到大大的好处。

上层发出event，下层分解执行并将各自的结果都放在统一的地方(Cache)，最后由上层来判定成功与否，是否发出持久化的event。

多谢banq

前半句我认同，后半句我不太认同，上层服务实际一个Order创建者或者说工厂，上层判断订单Order成功后，即可成功创建订单这个实体对象，返回给客户即可。至于订单这个实体是否持久化，是订单(聚合根)自己的实体职责，而不是上层服务应该关心的。

上层服务关心的是完成订单创建，而不是订单是否持久化。这两者是有区别的。

呵呵，有点较真，不过还是想改变大家的数据库思维，不要老是用数据库持久化来替代业务概念，否则SOA或DDD概念白提了。

呵呵，没看到持久化 就是不放心啊， 总感觉“春晚没接地气”.