一个常见但不是那么容易的架构问题

基本是这样，消息+服务，每个系统之间都是和服务(Web服务)接口耦合，服务的调用有通过消息或通过服务发现机制实现同步调用两种方式，基于服务的方式易于发展为平台。

提供一个参考：Steve Yegge对Amazon和Google平台的长篇大论：

1) 所有团队的程序模块都要以透过Service Interface 方式将其数据与功能开放出来。（陈皓注：Service Interface也就是Web Service）
2) 团队间的程序模块的信息通信，都要透过这些接口。
3) 除此之外没有其它的通信方式。其他形式一概不允许：不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等，等等，唯一允许的通信方式只能是能过call Service Interface。
4) 任何技术都可以使用。比如：HTTP、Corba、Pubsub、自定义的网络协议、等等，都可以，Bezos不管这些。（陈皓注：Bezos不是微控经理吗？呵呵。）
5) 所有的Service Interface，毫无例外，都必须从骨子里到表面都要设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便把接口开放给全世界的程序员，没有例外。
6) 不这样的做的人会被炒鱿鱼。
7) 谢谢，祝你有个愉快的一天！

[该贴被banq于2011-11-05 07:58修改过]

对，我们是做了个能力层、服务层、服务管理层、客户端调用层，各层通过web服务或消息进行发现或者调用。但是在服务层内部，2个服务之间，需要继续考虑边界划分，比如发帖和审批分属于前后台服务，可能是由不同小组开发，发帖服务发帖之后，缓存了帖子对象，审批服务审批之后，如何通知发帖服务更新？

我们现在是在前台发帖服务增加了一个通知接口，后台审批通过时，1个后台审批通过服务实例向多个前台发帖服务实例发送异步的已审批通过通知。如果前台服务崩溃，后台审批可以照样进行，当前台服务重启时，会加载已审批的结果。

老彭，还有更优雅的做法吗。

成熟做法基本是这样，如果还有什么问题的话，根据问题有不同方向选择，比如可以向Event Sourcing方向发展，以事件为主要考虑；或者象Amazon那样从SOA发展为云计算平台。

嗯！soa->cloud，一个很自然的演化结果。

event sourcing这样的利刃，密切关注！