一起玩轉微服務(5)——分層架構

skyme發表於2020-06-19

領域驅動設計DDD(Domain Driven Design)提出了從業務設計到程式碼實現一致性的要求,不再對分析模型和實現模型進行區分。也就是說從程式碼的結構中我們可以直接理解業務的設計,命名得當的話,非程式人員也可以“讀”程式碼。這與微服務設計中的約定優於配置不謀而合,如果你熟悉英文,那麼直接根據包名和類名就可以直接解讀出程式開發者所構建的業務的大概意圖。

領域模型包含一些明確定義的型別:

  • 實體是一個物件,它有固定的身份,具有明確定義的"連續性線索"或生命週期。通常列舉的示例是一個 Person(一個實體)。大多數系統都需要唯一地跟蹤一個 Person,無論姓名、地址或其他屬性是否更改。
  • l值物件沒有明確定義的身份,而僅由它們的屬性定義。它們通常不可變,所以兩個相等的值物件始終保持相等。地址可以是與 Person 關聯的值物件。
  • l集合是一個相關物件叢集,這些物件被看作一個整體。它擁有一個特定實體作為它的根,並定義了明確的封裝邊界。它不只是一個列表。
  • l服務用於表示不是實體或值物件的自然部分的操作或活動。

領域模型在實現時可大可小,在業務的早期,在系統比較小的情況下,它有可能是一個類。當系統做大了以後,它可能是個庫。再做更大一點的時候,它可能是一個服務,給不同的應用去呼叫。

要將領域元素轉換為服務,可按照以下一般準則來完成此操作:

  • 使用值物件的表示作為引數和返回值,將集合和實體轉換為獨立的微服務。
  • 將領域服務(未附加到集合或實體的服務)與獨立的微服務相匹配。
  • 每個微服務應處理一個完整的業務功能。

領域模型又可以分為失血、貧血和充血3種。

  • 失血模型:基於資料庫的領域設計方式就是典型的失血模型,只關注資料的增刪改查。
  • 貧血模型:就是在domain object包含了不依賴於持久化的領域邏輯,而那些依賴持久化的領域邏輯被分離到server層。
  • 充血模型:充血模型跟貧血模型差不多,不同的是如何劃分業務邏輯,就是說,約大部分業務應該放到domain object裡面,而service應該是很薄的一層。

設計原則之分層架構

同一公司使用統一應用分層,以減少開發維護學習成本。應用分層這件事情看起來很簡單,但每個程式設計師都有自己的一套,哪怕是初學者,所以想實施起來並非那麼容易。

最早接觸分層架構的應該是我們最熟悉的MVC(Model-View-Controller)架構,將應用分成了模型、檢視和控制層,可以說引導了絕大多數開發者,而我們現在的應用中非常多的包括框架,架構設計都使用此模式。這後又演化出了MVP(Model-View-Presenter)和MVVM(Model-View-ViewModel)。這些可以說都是隨著技術的不斷髮展,為了應對不同場景所演化出來的模型。而微服務的每個架構都可以再細分成領域模型,下面看一下經典的領域模型架構。

它包括了Domain,Service Layer和Repositories。核心實體(Entity)和值物件(Value Object)應該在Domain層,定義的領域服務(Domain Service)在Service Layer,而針對實體和值物件的儲存和查詢邏輯都應該在Repositories層。值得注意的是,不要把Entity的屬性和行為分離到Domain和Service兩層中去實現,即所謂的貧血模型,事實證明這樣的實現方式會造成很大的維護問題。基於這種設計,工程的結構可以構造為:

- MicroService-Sample/src/

    domain

    gateways

    interface

    repositories

    services

當然,在微服務的架構中,每個微服務不必嚴格遵照這樣的規定,切忌死搬硬套,最重要的是理解,在不同的業務場合,架構的設計可以適當的做調整,畢竟適合的架構一定要具有靈活性。

分層的原則包括:

  • 資料夾分層法

應用分層採用資料夾方式的優點是可大可小、簡單易用、統一規範,可以包括 5 個專案,也可以包括 50 個專案,以滿足所有業務應用的多種不同場景。

  • 呼叫規約

在開發過程中,需要遵循分層架構的約束,禁止跨層次的呼叫。

  • 下層為上層服務

以使用者為中心,以目標為導向。上層(業務邏輯層)需要什麼,下層(資料訪問層)提供什麼,而不是下層(資料訪問層)有什麼,就向上層(業務邏輯層)提供什麼。

  • 實體層規約

Entity是資料表物件,不是資料訪問層物件;DTO 是網路傳輸物件,不是表現層物件;BO 是記憶體計算邏輯物件,不是業務邏輯層物件,不是隻能給業務邏輯層使用 。如果僅限定在本層訪問,則導致單個應用內大量沒有價值的物件轉換。以使用者為中心來設計實體類,可以減少無價值重複物件和無用轉換。

  • U 型訪問

下行時表現層是 Input,業務邏輯層是 Process,資料訪問層是 Output。上行時資料訪問層是 Input,業務邏輯層是 Process,  表現層就 Output。

相關文章