DDD(八)--聚合一致性

一、引言

偶然看到分佈式事務一致性的解決方案，想起DDD中聚合也有一致性的概念。

---

二、一致性

一致性可分爲三種：

• 強一致性
• 弱一致性
• 最終一致性

強一致性，也能夠稱之爲實時一致性。當更新操做完成以後，任何多個後續進程或者線程的訪問都會返回最新的更新過的值。這種是對用戶最友好的，就是用戶上一次寫什麼，下一次就保證能讀到什麼。根據 CAP 理論，這種實現須要犧牲可用性。

弱一致性，系統並不保證續進程或者線程的訪問都會返回最新的更新過的值。系統在數據寫入成功以後，不承諾當即能夠讀到最新寫入的值，也不會具體的承諾多久以後能夠讀到。

最終一致性，弱一致性的特定形式。系統保證在沒有後續更新的前提下，系統最終返回上一次更新操做的值。在沒有故障發生的前提下，不一致窗口的時間主要受通訊延遲，系統負載和複製副本的個數影響。DNS 是一個典型的最終一致性系統。

在工程實踐上，爲了保障系統的可用性，互聯網系統大多將強一致性需求轉換成最終一致性的需求，並經過系統執行冪等性的保證，保證數據的最終一致性。

舉個例子：假設咱們10我的，每人有一個帳號，裏面有錢，能夠轉來轉去，這組成了一個小型的數據系統，那麼什麼叫數據一致性？這是由你本身來定義的，比較通用的就是：這10我的的帳號金額總數不變——知足這一條件，就叫數據一致，不知足，就叫數據不一致，或者在分佈式的環境下，有一個數據在幾個地方都保存了，那麼任什麼時候候，這幾個地方的數據都必須相同，這也叫一致性。 如今咱們就這個簡單的一致性規則：10我的的帳號金額總數不變。假設初始的時候每一個人帳號裏有一萬，A帳號往B帳號裏轉5000，這時候數據庫要執行兩行代碼：

A：減去5000

B：加上5000

在執行完第一行代碼的時候，這時候數據是不知足一致性條件的！必需要執行完第二行代碼，數據才恢復到一致性的狀態！換而言之，數據庫中的數據是常常處於不一致的狀態，這是不可避免的，所以咱們提出了事務的概念，用於檢測數據庫中的數據是否處於一致性狀態——若是數據庫中有沒有執行完的事務，那就是不一致的，不然，就是一致的。 上面的例子只是最簡單的狀況，實際的運用中要複雜得多，好比前面提到的分佈式系統：某個數據存在了三個服務器上，如今要更新，就必須保證三個服務器上全都更新好，若是有一個沒有成功，那麼其餘兩個也應該維持不變。

來源：http://www.javashuo.com/article/p-ovpgydmu-ev.html

---

三、聚合一致性

從聚合的維度考慮，一致性分爲「內部一致性」和「外部一致性」。內部一致性是指一個聚合實例自己狀態的一致性。外部一致性是指多個聚合實例之間狀態的一致性。

聚合是領域對象的顯示分組，旨在支持領域模型的行爲和不變性，同時充當一致性和事務性邊界。

這句話涉及到幾個概念，咱們來拆解一下：

1. 聚合是領域對象的顯示分組
2. 領域行爲和不變性
3. 一致性和事務性邊界

領域不變性指的是必須遵照的陳述或規則。換句話說，就是領域內咱們關注的業務規則。

好比建立一個訂單，必然會生成訂單詳情，訂單詳情確定會有商品信息，咱們在修改商品信息的時候，確定就不能影響到這個訂單詳情中的商品信息。再好比：用戶在下單的時候，會選擇一個地址做爲郵寄地址，若是該用戶馬上下另外一個訂單，並對本身我的中心的地址進行修改，確定就不能影響剛剛下單的郵寄地址信息。

這個時候，聚合就有很強的做用，經過值對象保證了對象之間的一致性。咱們平時在開發的時候，雖然沒有用到DDD，確定也是常常用到聚合，就好比上邊的問題，撇開DDD不談，就平時來講，你確定不會把商品 id 直接綁定到訂單詳情表中，爲外鍵的，否則會死得很慘。這個時候其實咱們就有一些聚合的概念了，由於什麼呢，下單的時候，咱們關注訂單領域模型，修改商品的時候，咱們關注商品領域模型，這些就是咱們說到的聚合。

咱們再結合上面拆解的三點就能夠理解了，聚合就是領域對象的動做和行爲的一個顯示的表現，在領域內聚合中的實體保持的強一致性的特色，可是對外有的時候是保持的弱一致性（當商品聚合中的商品改變時，訂單聚合中的商品信息不變）有些時候是最終一致性（當用戶聚合中的金額減小時，因交易還未完成，因此商家是不會收到貨款，可是最後用戶簽收時，商家才收到貨款），這就是事務性邊界。