我对此有些疑问，大家讨论一下
在banq看来，基于ddd设计的软件，其扩展性依赖于ehcache等分布式缓存的扩展性。
而ehcache节点间的同步是比较低效的，只要是通过网络改变状态的同步方法，扩展性肯定不如memcached，因为memcached节点间是不用通讯的。比如100个节点，memcached的效率比echcache高得多。
实例也是如此。facebook有世界上最大的memcached集，facebook主要是php写成的，php当然不会用ddd了。php和memcached结合的应用很多。
实例中有大规模的echcache集群吗？如果有，请大家告知一下。
memcached本质不是对象缓存，需要经过序列化和反序列化处理。
ehcache是对象缓存，不需要经过序列化处理。
单机性能肯定是ehcache好，分布后我就有些担心了。
现在ehcache其实就是兵马俑 terracotta
见这个帖子比较：
缓存： Memcached和terracotta
总得来说，正如你说，ehcache/terracotta属于集群性质的分布式，强调稳定性和可靠性，拓展性不好，而MemCached则可靠性不太好。
对于企业应用比较侧重可靠性；对于社区应用，比较侧重拓展性，这里就涉及分布式架构设计原则CAP原理，根据不同项目进行选择。
[该贴被banq于2010-12-04 08:44修改过]
回复得很清晰，谢谢。
另外，你主张把域对象放到缓存中，这样的话就失去了数据库的一个特性: 事务，尤其是持久性，机器突然坏了，内存的数据就丢失了，而数据库就不会。
当然不是所有的应用都有事务的要求。
对事务要求很严的应用，数据库的作用还是不可忽略的，因为通过应用层和缓存实现ACID是比较困难的.
缓存的最初目的是缓解数据库的压力，缓存要取代数据库的地位，就要很好的持久化设计。就像linux的虚拟内存和文件系统的关系，linux的虚拟内存的设计很精妙，也很复杂。缓存要取代数据库，那最终的解决方案还是基于内存的对象数据库。
这里的根本点在于内存和文件系统的关系，内存快，文件系统慢，缓存基于内存，数据库基于文件系统。
所以我认为ddd真正需要的是基于内存的对象数据库，而不是缓存，缓存还是太简单了。
基于缓存的ddd只能适用于部分对事务要求不严的应用。
基于orm的ddd则适用于对事务有严格要求的应用，其扩展性最终还是得依赖于数据库。
以上拙见，请道友们指教
[该贴被niyunjiu于2010-12-04 13:31修改过]
你说得有道理，通过缓存的引入，可以让我们重新思考过去缺省都是事务的习惯，使用缓存，你就必须考虑哪些不需要事务，从而对你的业务进行事务精确化，这样是提供可伸缩性最好的办法，因为事务是可伸缩性的敌人。
当我们很小心处理事务之后，这部分事务还是可以使用Java内存锁机制或者Scala的内存事务等来完成，相信随着技术进步，摆脱数据库事务的内存事务是一个趋势。