看了xmuzyu的回复，获益不少。但还有些问题要继续讨论。

看来缓存主要控制那些业务对象被放入内存，取出和放入大概类似于获得和释放一个引用。问题是通用的缓存框架是否足够灵活和可控，能很好的完成这个工作。由于缓存根本和业务无关，恐怕很难根据实际业务需求决定是否把业务对象放入内存。

我也同意近则快，但是这不等于减少物理I/O。从数据服务器cache到应用服务器需要网络开销，但是分布式缓存同样有这个问题。数据库cache不了解也业务，但是业务是由业务对象控制，甚至并行读写也要业务对象自己完成，不明白缓存如何根据业务需求缓存。

OO确实使系统逻辑清晰，但是我不认为用好OO就没性能问题。比如根据订单类型执行不同操作，对于过程编程，用if-else实现，对于机器可能就是一个跳转指令。用OO，至少也要涉及函数调用，执行复杂度差很多。

用好OO相对于用不好，可能性能会好。但是并不等于用好OO就是最好的性能的方案。你用的再好，也和汇编编程比不了性能。

我说说我自己的理解。

首先，后面部分的讨论都是在考虑缓存和性能的问题。其实在这里，我觉得性能有两个方面，第一个方面就是“系统有多快”也就是给定的任务需要多长时间来完成，第二个方面就是“系统到底能做多少工作”这其实就是吞吐量。我们采用面向对象设计+缓存的设计方式好处就是从性能的这两个方面着手进行了考虑。在“系统有多快”方面，通过缓存可以显著减少响应需要时间，而在“系统到底能做多少”方面，这个方面其实就是系统的水平伸缩性（通过增加工作单元所需的资源，吞吐量就能显著地提高），当通过面向对象的设计，设计好对象以后，这个对象放入缓存，缓存可以采用分布式的缓存系统，而这样其实是一种伸缩性的方案。

还有比如我们为什么讲究分层架构，系统分那么多层反而使得性能的第一方面“系统有多快”受到不好的影响，但是为什么我们还要分层，我觉得我们这个时候关注的可扩展性和系统的伸缩性，这其实就是性能的第二个方面，当系统被合理的分层解耦以后，每个层都可以独立的伸缩，而如果直接不分层，这个系统的伸缩性也就指望垂直伸缩了，也就是靠更强大的CPU，靠速度更快的磁盘等。

所以我觉得使用面向对象的设计+缓存是从性能两个方面进行了考虑的，而不能只从快的方面考虑，还有伸缩性的原因。

以上是自己的理解。

>>>1）缓存既是持久存储的附庸，它必得跟持久存储走。持久存储是记录集，如果缓存的是对象或其它与记录集大相径庭的东西，这缓存势必带来很大的附加开销。因此，我说，不是一缓存，效率就上去了，说不定反而下降。

我是菜鸟，有点不明白，为什么你认为“缓存既是持久存储的附庸，它必得跟持久存储走”？你从哪儿得到的结论说“缓存既是持久存储的附庸”？

缓存是数据在内存的“家”（使用缓存的话），我认为和持久化存储是并列的，最起码在运行时缓存的数据是一致的，就更不要说7X24的缓存了

>>你的意思是仓库控制了缓存访问？应该是工厂吧，呵呵，我大概知道你一点意思，其实在service里也可以直接从缓存中获得某个聚合根对象。

我对DDD中提到的Factory和Repository的理解是： factory应该是 创建 对象，而Repository是 重建 对象，当然他们都应该满足一致性。

我认为我们不应该在service中直接从缓存中获取对象（当然不是说不能）。当我们不能从缓存中获取数据时，我们需要从数据库加载；当我们不在一个统一的对象中控制 对象的访问，我们的代码中将出现重复的判断“如果缓存中没有就从数据库加载”。

建议楼主多从需求角度来思考缓存。
看看这缓存如何应对外部访问而提高效率。

感谢板桥
我终于在迷失2年后找到我需要的路。谢谢了。对于 缓存 锁 如何学习请给与指点 最终目标与OO一致也就是你所谓的大道。 再次感谢！

这些概念一个核心就是内存中领域模型，领域模型属于OO，而内存属于架构，领域模型是生存在内存中，缓存属于内存，NoSQL也属于内存，锁是对内存中对象并发进行控制的策略。

圣教主千秋万代,一统江湖

俺来的虽然很晚，但是我看到了很多有用的东西

我來的更晚，但是我看到了很多有用的东西

mark 缓存