之前分享過DDD，到底與微服務的關係如何？很多人還是覺得很虛幻，DDD那麼複雜的理論，聚合根、值物件、事件溯源，到底我們該怎麼入手呢？
實際上DDD和麵向物件設計、設計模式等等理論有千絲萬縷的聯絡，如果不熟悉OOA、OOD，DDD也是使用不好的。不過學習這些OO理論的時候，大家往往感覺到無用武之地，因為大部分的Java程式設計師開發生涯是從學習J2EE經典的分層理論開始的（Action、Service、Dao），在這種分層理論中，我們基本沒有啥機會使用那些所謂的“行為型”的設計模式，這裡的核心原因，就是J2EE經典分層的開發方式是“貧血模型”。

Martin Fowler在他的《企業應用架構模式》這本書中提出了兩種開發方式“事務指令碼”和“領域模型”，這兩種開發分別對應了“貧血模型”和“充血模型”。

事務指令碼開發模式

• 事務指令碼的核心是過程，可以認為大部分的業務處理都是一條條的SQL，事務指令碼把單個SQL組織成為一段業務邏輯，在邏輯執行的時候，使用事務來保證邏輯的ACID。最典型的就是儲存過程。當然我們在平時J2EE經典分層架構中，經常在Service層使用事務指令碼。

使用這種開發方式，物件只用於在各層之間傳輸資料用，這裡的物件就是“貧血模型”，只有資料欄位和Get/Set方法，沒有邏輯在物件中。

我們以一個庫存扣減的場景來舉例：

• 業務場景
  首先談一下業務場景，一個下訂單扣減庫存（鎖庫存），這個很簡單
  先判斷庫存是否足夠，然後扣減可銷售庫存，增加訂單佔用庫存，然後再記錄一個庫存變動記錄日誌（作為憑證）
• 貧血模型的設計
  首先設計一個庫存表 Stock，有如下欄位

設計一個Stock物件(Getter和Setter省略)

public class Stock {
	private String spuId;
	private String skuId;
	private int stockNum;
	private int orderStockNum;
}
 

Service入口，設計一個StockService，在其中的lock方法中寫邏輯，入參為(spuId, skuId, num)

count = select stocknum from stock where spuId=xx and skuid=xx
if count>num {
     update stock set stocknum=stocknum-num, orderstocknum=orderstocknum+num  where skuId=xx and spuId=xx
} else {
     //庫存不足，扣減失敗
}
insert stock_log set xx=xx, date= new Date()
 

ok，如果做的好一些，可以把update和select count合一，這樣可以利用一條語句完成自旋，解決併發問題（高手）。

小節

有沒有發現，在這個業務領域非常重要的核心邏輯 – 下訂單扣減庫存中操作過程中，Stock物件根本不用出現，全部是資料庫操作SQL，所謂的業務邏輯就是由多條SQL構成。Stock只是CRUD的資料物件而已，沒邏輯可言。

• 馬丁福勒定義的“貧血模型”是反模式，面對簡單的小系統用事務指令碼方式開發沒問題，業務邏輯複雜了，業務邏輯、各種狀態散佈在大量的函式中，維護擴充套件的成本一下子就上來，貧血模型沒有實施微服務的基礎。

• 雖然我們用Java這樣的面嚮物件語言來開發，但是其實和過程型語言是一樣的，所以很多情況下大家用資料庫的儲存過程來替代Java寫邏輯反而效果會更好，（ps：用了Spring boot也不是微服務），

領域模型的開發模式

• 領域模型是將資料和行為封裝在一起，並與現實世界的業務物件相對映。各類具備明確的職責劃分，使得邏輯分散到合適物件中。這樣的物件就是“充血模型” 。
• 在具體實踐中，我們需要明確一個概念，就是領域模型是有狀態的，他代表一個實際存在的事物。還是接著上面的例子，我們設計Stock物件需要代表一種商品的實際庫存，並在這個物件上面加上業務邏輯的方法

這樣做下單鎖庫存業務邏輯的時候，每次必須先從Repository根據主鍵load還原Inventory這個物件，然後執行對應的lock(num)方法改變這個Inventory物件的狀態（屬性也是狀態的一種），然後再通過Repository的save方法把這個物件持久化到儲存去。
完成上述一系列操作的是Application,Application對外提供了這種整合操作的介面

領域模型開發方法最重要的是把扣減造成的狀態變化的細節放到了Inventory物件執行，這就是對業務邏輯的封裝。
Application物件的lock方法可以和事務指令碼方法的StockService的lock來做個對比，StockService是完全掌握所有細節，一旦有了變化（比如庫存為0也可以扣減），Service方法要跟著變；而Application這種方式不需要變化，只要在Inventory物件內部計算就可以了。程式碼放到了合適的地方，計算在合適層次，一切都很合理。這種設計可以充分利用各種OOD、OOP的理論把業務邏輯實現的很漂亮。

• 充血模型的缺點
  從上面的例子，在Repository的load 到執行業務方法，再到save回去，這是需要耗費一定時間的，但是這個過程中如果多個執行緒同時請求對Inventory庫存的鎖定，那就會導致狀態的不一致，麻煩的是針對庫存的併發不僅難處理而且很常見。
  貧血模型完全依靠資料庫對併發的支撐，實現可以簡化很多，但充血模型就得自己實現了，不管是在記憶體中通過鎖物件，還是使用Redis的遠端鎖機制，都比貧血模型複雜而且可靠性下降，這是充血模型帶來的挑戰。更好的辦法是可以通過事件驅動的架構來取消併發。

領域模型和微服務的關係

上面講了領域模型的實現，但是他和微服務是什麼關係呢？在實踐中，這個Inventory是一個限界上下文的聚合根，我們可以認為一個聚合根就是一個微服務程序。
不過問題又來了，一個庫存的Inventory一定和商品資訊是有關聯的，僅僅靠Inventory中的冗餘那點商品ID是不夠的，商品的上下架狀態等等都是業務邏輯需要的，那不是又把商品Sku這樣的重型物件引入了這個微服務？兩個重型的物件在一個服務中？這樣的微服務拆不開啊，還是必須依靠商品庫？！
請參考下一篇，通過事件驅動架構來完成領域間的鬆耦合。