講解完【值物件】與【實體】，我們可以瞭解到他們之間的區別與聯絡，以及他們各自的適用場景。在一些場景下【實體】的唯一性可以用【值物件】進行表達。本文主要分享一下【實體】的持久化操作，在這裡強烈推薦  Spring-Data-JDBC  面向DDD的資料框架，該框架實現了 【實體】【聚合】以及【事件】之間的關係以及他們的觸發機制。基本是基於DDD思想的程式碼實現。

       【實體】建立完畢後，最終都要基於某種技術對其進行持久化，儲存含【實體】的【資料】以及當時的【狀態】，以便於在需要的時候，可以從持久化的介質中還原，從儲存的【斷點】處，保證程式可以繼續執行。 這就是【實體】持久化最原始的目的，圍繞這個目的的實現，我們可以採用多種持久化的手段實現：1、基於記憶體，2、基於文件   3、基於資料庫（關係型、文件型等） ......。不同的存取方式各有利弊，目前我們主體都是基於 關係型資料庫進行【實體】的持久化實現。

    1、  基於資料庫的持久化，不得不提到大名頂頂的ORM框架（Hibernate、JPA）等是類似的框架，物件的每個屬性，對映資料庫的具體列欄位，自動生成SQL完成資料庫的持久化，不得不說其功能的強大。我們在使用這些框架的時候，不知不覺就陷入一種思維定性：資料庫的使用定性。一想到【實體】建模，第一就是考慮資料庫的表結構以及儲存本身，忽略我們對【實體】本身應該聚焦的考慮因素：如【唯一性】、【行為】、【關鍵屬性】等。

   2、在一定程式需要把DB看作Document，並不是每個欄位都只儲存一個業務屬性，當前我採用大量json格式的字串儲存到一個欄位中,在這個角度看，持久化時過程，儲存的結果時目的。站在DBA的指令碼肯定會瘋掉的。

    2、儲存、修改、刪除【實體】等這些都需要進行持久化操作，這些操作都因該支援冪等操作，如果更新的【實體】與持久化到資料庫中的【實體】是相等的，那麼該操作本身是應該被忽略的。

   3、儲存物件不再是一個【實體】，而是一個【聚合】的時候，需要引入事務的概念，在DDD模型下，這個處理比較棘手一些，目前的事務都基於單個數據庫的場景進行討論，目前Spring框架的事務處理機制提供的比較的普遍一些，也支援多種不同場景的策略模式。分散式模式下，事務就需要採用其他的模式或者程式設計技巧進行額外的處理。

   4、持久化【實體】或者其他，不僅僅要持久化物件本身，還需要持久當時的業務上下文，便於下次還原時，順帶還原當時的業務上下文。

   目前，對我而言，持久化時儲存，可以把【實體】當作時圖書，DB則是圖書館，每次借書、還書都採用圖書館裡的管理模式，

   DDD 領域思想，持久化強調了冪等的重要性，物件當時執行的上下文以及如何寫入與讀取這些資訊，可能時【值物件】、【實體】或者【聚合】等。以及基於領域的事件驅動模型的建立。提前講解一下  DDD比較推崇的一些架構實現時採用 CQRS 模式。與事件驅動密閉可分。後期會逐步講解。

   週日，比上班有時候都辛苦~~ 也佩服孩子的精力彷彿永遠用不完，