1. 程式人生 > >一起玩轉微服務(5)——分層架構

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

領域驅動設計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。

相關推薦

一起服務5——分層架構

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

一起服務1——概念

一、什麼是微服務 隨著各行各業公司的快速發展,業務規模的不斷擴大,不可避免的造成原有架構不能夠適應快速的增長和變化。這時,微服務就進入大家的視野,其實在微服務之前,很多的公司已經做過服務化的改造,並且取得了一定的成果,但是對於整體流程的標準化還有一定有差距。那麼,什麼是微服務呢?準確的說,微服務是一種軟體架構

一起服務2——框架與工具

一、微服務架構有哪些優勢? 獨立開發 – 所有微服務都可以根據各自的功能輕鬆開發· 獨立部署 – 基於其服務,可以在任何應用程式中單獨部署它們· 故障隔離 – 即使應用程式的一項服務不起作用,系統仍可繼續執行· 混合技術堆

一起服務3——服務架構設計模式

一、聚合器微服務設計模式 這是一種最常見也最簡單的設計模式,效果如下圖所示。聚合器呼叫多個服務實現應用程式所需的功能。它可以是一個簡單的Web頁面,將檢索到的資料進行處理展示。它也可以是一個更高層次的組合微服務,對檢索到的資料增加業務邏輯後進一步釋出成一個新的微服務,這符合DRY原則。另外,每個服務都有自己的

一起服務4——如何實施服務

一、如何實施微服務 微服務是一種架構的理念,提出了微服務的設計原則,從理論為具體的技術落地提供了指導思想。實施微服務需要具備以下條件: 計算和儲存資源能否快速的分配 是否具備快速部署的能力,因為微服務每個服務都比較微小,所以不管是測試環境還是生產環境都需要快速部署的能力 基本的監控,包括CPU、記憶體、網路

一起服務6——通訊協議如何統一

一、介面呼叫 介面呼叫如果是遠端呼叫,那麼就構成了簡單的分散式。最簡單的遠端介面實現方式是web service或rest。當然一個合理的分散式應用不僅僅是遠端介面呼叫這麼簡單。還需要有負載均衡、快取等功能。最簡單實現分散式的技術是Rest介面,因為Rest介面可以使用現存的各種伺服器,比如負載均衡伺服器和快

一起服務7——單一職責

  單一職責 單一職責原則(Single Responsibility Principle, SRP):一個類只負責一個功能領域中的相應職責,或者可以定義為:就一個類而言,應該只有一個引起它變化的原因。 單一職責原則是實現高內聚、低耦合的指導方針,它是最簡單但又最難運用的原則 單一職責原則是最簡

一起服務9——前後端分離

前後端分離 在傳統的web應用開發中,大多數的程式設計師會將瀏覽器作為前後端的分界線。將瀏覽器中為使用者進行頁面展示的部分稱之為前端,而將執行在伺服器,為前端提供業務邏輯和資料準備的所有程式碼統稱為後端。 由於前後端分離這個概念相對來說剛出現不久,很多人都是隻聞其聲,不見其形,所以可能會對它產生一些誤解,誤以

一起服務10——spring boot介紹

對於Spring,相信大家都非常熟悉,從出現開始,一直是企業級開發的主流。但是隨著軟體的發展和應用開發的不斷演化,它的一些缺點也逐漸胡暴露了出來,下面,我們就一起看一下Spring的發展歷程並且認識一下Spring Boot。 由來 在Spring 1.x的時候,所有的配置都通過XML,隨著專案的擴大,需要頻

一起服務11——一切從簡單開始

介紹 使用Spring Bboot是快樂並且簡單的,不需要繁瑣的配置就能夠完成一套非常強大的應用。 spring boot 2.3.1 Spring Boot 2.3.1 釋出於:2020/06/12,現在已經提交到 Spring 倉庫和 Maven 中央倉庫了。 這個版本包括 127 個 bug 修復、S

一起服務12——揭密starter

介紹 Spring Boot的starter主要用來簡化依賴用的,對於企業級開發中的與第三方的整合,可以通過一段簡單的配置來完成,這樣開發人員無需再對包依賴的問題頭疼。Spring Boot為我們提供了簡化企業級開發的絕大多數場景的starter pom,只需要指定需要配置的starter,Spring Bo

一起服務13——AOP

一、什麼是AOP程式設計 AOP: Aspect Oriented Programming 面向切面程式設計。   面向切面程式設計(也叫面向方面):Aspect Oriented Programming(AOP),是目前軟體開發中的一個熱點。利用AOP可以對業務邏輯的各個部分進行隔離,從而使得業務邏輯各部分

一起服務14——單元測試

作為一名java開發者,相信你或多或少的接觸過單元測試,對於測試來講它是一門能夠區分專業開發人員與業餘開發人員的重要學科,這篇文章將對java中最常見的一個單元測試框架junit進行一個梳理和講解。 為什麼需要單元測試 在平時的開發當中,一個專案往往包含了大量的方法,可能有成千上萬個。如何去保證這些方法產生的

Spring Cloud學習筆記11——天氣預報系統服務5城市資料 API 服務

開發環境 JDK8+ Gradle4+ Spring Boot Web Starter 建立專案 新建專案資料夾: 將micro-weather-report專案中的原始碼檔案複製貼上到新專案資料夾中: 修改原始碼 修改build.gradle配置,刪除

鏡像的分層結構 - 每天5分鐘容器技術11

數據 9.png upload 問題: 所有 rfi image tle acs Docker 支持通過擴展現有鏡像,創建新的鏡像。 實際上,Docker Hub 中 99% 的鏡像都是通過在 base 鏡像中安裝和配置需要的軟件構建出來的。比如我們現在構建一個新的鏡像,

replicated vs global mode - 每天5分鐘 Docker 容器105

docker容器教程swarmSwarm 可以在 service 創建或運行過程中靈活地通過 --replicas 調整容器副本的數量,內部調度器則會根據當前集群的資源使用狀況在不同 node 上啟停容器,這就是 service 默認的 replicated mode。在此模式下,node 上運行的副本數有多

服務Microservices 簡介

rabbit 編程語言 不可 可能 通過 區別 clas 管理 基礎設施 概念 微服務架構風格是一種將單個應用程序作為一套小型服務開發的方法,每種應用程序都在自己的進程中運行, 並與輕量級機制(通常是HTTP資源API)進行通信。 這些服務是圍繞業務功能構建的

迪士尼源碼搭建與如何服務

service 優勢 cloud 穩定性 經驗總結 避免 讀者 拆分 部署 微服務,軟件應用開發的新紀元2014年 Martin Fowler 在《MicroServices》論文中首次提出了微服務的概念。近些年,伴隨著互聯網的日益發展,微服務在國內、甚至國際上的發展已達到

基於天氣預報項目談springcloud構建的服務

個人理解 動態 spring 解決方案 消費 服務架構 方式 mage 什麽是 單體架構 簡單介紹一下四個模塊分別的作用: 城市信息模塊: 主要是調用第三方服務獲取所有的城市信息,用於數據采集的時候調用 數據采集模塊: 由於是基於調用第三方 api 的服務,所以我們要考

一、服務Microservices【翻譯】

1、說明 本文轉載自 http://www.cnblogs.com/liuning8023/p/4493156.html 經典好文! 2、微服務 “微服務架構(Microservice Architecture)”一詞在過去幾年裡廣泛的傳播,它用於描述一種設計應用程式的特別方式,作為一套獨