微服務下DDD的充血模式
1 Star2 Stars3 Stars4 Stars5 Stars 給文章打分!
Loading...

之前分享過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這樣的重型物件引入了這個微服務?兩個重型的物件在一個服務中?這樣的微服務拆不開啊,還是必須依靠商品庫?!
請參考下一篇,通過事件驅動架構來完成領域間的鬆耦合。

相關文章

程式語言 最新文章