多研究些架構，少談些框架（ 2 ）：微服務和充血模型
實際上DDD和面向對象設計、設計模式等等理論有千絲萬縷的聯系，如果不熟悉OOA、OOD，DDD也是使用不好的。不過學習這些OO理論的時候，大家往往感覺到無用武之地，因為大部分的Java程序員開發生涯是從學習J2EE經典的分層理論開始的（Action、Service、Dao），在這種分層理論中，我們基本沒有啥機會使用那些所謂的“行為型”的設計模式，這裏的核心原因，就是J2EE經典分層的開發方式是“貧血模型”。
Martin Fowler在他的《企業應用架構模式》這本書中提出了兩種開發方式“事務腳本”和“領域模型”，這兩種開發分別對應了“貧血模型”和“充血模型”。
事務腳本開發模式
事務腳本的核心是過程，可以認為大部分的業務處理都是一條條的SQL，事務腳本把單個SQL組織成為一段業務邏輯，在邏輯執行的時候，使用事務來保證邏輯的ACID。最典型的就是存儲過程。當然我們在平時J2EE經典分層架構中，經常在Service層使用事務腳本。
使用這種開發方式，對象只用於在各層之間傳輸數據用，這裏的對象就是“貧血模型”，只有數據字段和Get/Set方法，沒有邏輯在對象中。
我們以一個庫存扣減的場景來舉例：
業務場景
首先談一下業務場景，一個下訂單扣減庫存（鎖庫存），這個很簡單
先判斷庫存是否足夠，然後扣減可銷售庫存，增加訂單占用庫存，然後再記錄一個庫存變動記錄日誌（作為憑證）
貧血模型的設計
首先設計一個庫存表 Stock，有如下字段
設計一個Stock對象(Getter和Setter省略)
1
2
3
4
5
6
public class Stock {
private String spuId;
private String skuId;
private int stockNum;
private int orderStockNum;
}
Service入口
設計一個StockService，在其中的lock方法中寫邏輯
入參為(spuId, skuId, num)
實現偽代碼
1
2
3
4
5
6
7
count = select stocknum from stock where spuId=xx and skuid=xx
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這樣的重型對象引入了這個微服務？兩個重型的對象在一個服務中？這樣的微服務拆不開啊，還是必須依靠商品庫？！
請參考下一篇，通過事件驅動架構來完成領域間的松耦合。
}
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這樣的重型對象引入了這個微服務？兩個重型的對象在一個服務中？這樣的微服務拆不開啊，還是必須依靠商品庫？！
請參考下一篇，通過事件驅動架構來完成領域間的松耦合。多研究些架構，少談些框架（ 2 ）：微服務和充血模型