內存緩存(in-memory cache)
當建立一個大型Java應用時，引起性能問題大部分是延遲，延遲是指請求和響應之間的時間差，在一個分佈式Java系統中引起延遲的原因有：
- 從磁盤上加裝數據的IO延遲
- 跨網絡加裝數據的IO延遲。
- 在分佈式鎖上的資源爭奪。
- 垃圾回收引起的暫停。
典型Ping時間是：本地機器是57µs；局域網是300 µs；從倫敦到紐約是100ms；對於1Gb網絡，網絡數據傳輸是每秒25MB – 30MB。對於10GB網絡是每秒250MB – 350MB。使用SATA 3.0接口的SSD硬盤數據傳輸是每秒500-600MB。如果你有1G以上數據需要處理，磁盤延遲會嚴重影響應用性能。
硬件上最低延遲是內存，典型的內存緩存是每秒3-5 GB，能夠隨着CPU擴展。如果你有兩個處理器，你就能每秒10GB，如果有4CPU就能獲得 20GB. 有一個內存基準測試稱爲STREAM (http://www.cs.virginia.edu/stream/) 是測試許多計算機的內存吞吐量，一些在大量CPU幫助下能夠實現每秒TB級別的吞吐量。
因此可以總結如下：
- 內存是快的: 爲了高性能，你需要在內存中處理數據。
- 網絡是慢的: 通過網絡傳輸數據會嚴重影響性能，包括數據庫連接池。
在許多應用中，應用的快速性能與數據實時更新需要尋找一個平衡點，有時你需要大膽地使用緩存，但是你可能會發現有舊髒數據現象發生，當然可以再抓取更新數據，但是可能會犧牲一些性能，你能，你可以魚和熊掌兼得，那麼就要花費購買更多硬件，增加軟件的複雜性。
內存緩存原來作用是提高數據庫訪問性能。但是緩存不是數據庫遮羞布，架構上緩存引入有着重要意義：狀態對象：數據庫的替代者。
緩存實際是內存，將狀態置於內存而不是數據庫，不但性能提升，還提高軟件的可伸縮性和擴展性，直至輕鬆發展爲分佈式系統或雲計算，這種緩存稱爲內存緩存(in-memory cache)或稱 數據網格In-Memory-Data-Grid (IMDG)；Java EE 7引入分佈式 彈性緩存Elastic Caching ，作爲其雲核心戰略的一部分。 雲計算是一種計算和存儲分離的模型，雲計算本質是分佈式可伸縮的內存計算，可見Amazon彈性緩存介紹。
當我們將DDD領域模型加載到內存中以後，我們就不再面向關係數據庫中數據表編程，而是真正直接面向模型對象編程。Java內存模型優點：基於內存的併發模型，多線程機制，大量線程安全型庫包支持 基於內存的併發機制，粒度靈活控制，靈活度高於數據庫鎖。 多核並行計算模型 基於線程的異步模型(Domain Events)。
Twitter從Ruby轉向JAVA的實踐證明：Cache緩存 + JVM微調是Java/JVM的核心競爭力，這也是最容易被我們忽視的，因爲很多使用Java系統(包括Spring + Hibernate)只是當作SQL語句的包裝器來使用，負載主要集中在數據庫上，根本不會使用In-memory Cache。
Jdon認爲對象緩存恰好是領域模型和Java內存模型之間的銜接物，通過引入緩存，將領域模型落實到計算機平臺上，如下圖，基於此理念JdonFramework特點就是DDD + Cache，而Spring 3纔剛剛加入緩存，兩種框架相比可見關鍵性方向的不同：