微服務體系的分層設計和領域划分 一層一模型 應用層、領域層人員分工

小結：

1、

“一層一模型”本質是解耦模型依賴。

 

Java生鮮電商平台-SpringCloud微服務架構中核心要點和實現原理 - 巨人大哥 - 博客園 https://www.cnblogs.com/jurendage/p/11364846.html

Java生鮮電商平台-生鮮電商中微服務體系中的分層設計和領域划分？(小程序/APP) - 巨人大哥 - 博客園 https://www.cnblogs.com/jurendage/p/13795640.html

https://mp.weixin.qq.com/s/ZLi1WlAa6yQUZzO_SV18sQ

生鮮電商中微服務體系的分層設計和領域划分

互聯網后端架構   2020-12-13

 

5.Q&A

5.1 能不能在所有層使用數據持久層模型，簡單快捷？

大家一定聽說過不同層的數據模型的叫法不同的概念，比如數據持久層的模型對象叫DBO（database object）或者DPO（data persistence object),領域層的模型對象叫DMO（Domain Model Object）或者就叫Model，數據傳輸層的模型對象叫DTO（Data Transfer Object)。那為啥要這么多模型呢，直接使用Mybatis等ORM框架生成DBO，然后一路吐給前端不是更爽（還真有同事嘗試立項寫Mybatis插件來實現這種所謂的代碼自動化）。我個人建議如果您真的是要搭建一個復雜的大系統，大平台，一定不要偷這種懶，最好的就是做到”一層一模型”（網關層使用應用層模型即可）。各層之間采用手動的數據賦值（getter，setter）來完成，或者使用一些轉換框架來簡化轉換代碼，個人在用getter/setter時感覺並不會耽誤什么，在一個個set的時候，恰好可以對模型的字段細節進一步確認，並且拒絕使用BeanUtils.copyProperties()這種工具類，因為這樣的工具類會讓”一層一模型”形同虛設，開發會熱衷於把DPO拷貝到領域中換個名字以保證可以用拷貝工具。下面我們來細談下不能在每一層都是用數據持久層模型的具體原因：

• 應用層對接網關層，是向面向C端或者調用者的一個數據出口，但是調用者只需要這個出口輸出用戶感興趣的數據，並且有些敏感數據不能吐出去。如果應用層（面向調用者）使用的仍然是數據庫模型，而開發人員沒有在應用層把無關值置空的話（相信我，需求一多，工作一忙，鬼才會在意這些細節），那么數據庫里的整條記錄就作為接口輸出吐出去了。比如訂單記錄，用戶訂單列表可能只需要訂單ID，商品名稱，訂單金額。而像商家結算價這種就不能吐出去，萬一被有心人察覺到了，用戶一定會投訴——你跟商家結算價200，賣給我400？
• 前端或者接口調用方會很痛苦，一個接口契約多一兩個無關字段是沒關系的，但是一個契約里給的30個字段，我只用到5個，前端會罵娘的，我親眼見過這種事，設計原則里有個原則叫”迪米特法則”，也叫最小知識原則，接口設計也可以參考這個原則，盡量讓你的調用方知道盡可能少的信息點就能完成相關的任務。
• “一層一模型”本質是解耦模型依賴。我在上家公司做架構師時為了兼顧開發的感受，決定讓他們可以在領域層和基礎設施層都是用數據持久層模型，而只需要在應用層做數據控制（解決第一個問題），然而我的妥協也慢慢露出弊端，開發有時候覺得某個數據庫字段命名不合適修改之后，整個引用了該模型的微服務都需要修改，如果一層一模型的話，只需要關聯數據庫訪問的服務修改下DPO和DM的映射就行了，其他上層微服務都是依賴DM的。雖然我們不鼓勵隨意改動數據庫字段，但設計框架上最好能支持這種情況。

剛開始推廣”一層一模型”的時候，會有耍小聰明的開發去把下一層的模型POJO直接拷貝過來改個名字，然后用BeanUtils.copyProperties()完成賦值，這樣跟直接使用數據持久層模型就沒有區別了，所以要杜絕這種情況的發生。

Java生鮮電商平台-SpringCloud微服務架構中核心要點和實現原理 - 巨人大哥 - 博客園 https://www.cnblogs.com/jurendage/p/11364846.html

 

 

 

應用層開發人員設計接口和契約

領域層開發人員划分領域、設計領域服務接口

應用層開發人員編寫應用業務邏輯

領域層開發人員編寫領域業務邏輯