** 本文同步發表於 FB社群-軟體設計鮮思維 **
單體式的挫折,導致微服務的架構風格 – 將應用程序建構爲多個微服務
- 每一個微服務均視爲是一個小型的系統。
- 微服務各自擁有自己的私有倉儲 (資料庫)。
- 微服務之間的互動是透過 API 的介接。
- 每一個微服務是獨立的個體,所以可以爲各自的微服務採用不同的實作技術與系統的建置、部署及維護方式。
** 本文同步發表於 FB社群-軟體設計鮮思維 **
單體式的挫折,導致微服務的架構風格 – 將應用程序建構爲多個微服務
** 本文同步發表於 FB社群-軟體設計鮮思維 **
要談及微服務,就需要回頭檢視典型單體 (Monolithic) 式的系統建構與開發方式。下圖可能是一個醫療領域的單體式系統架構。
這個「Monolithic」可以翻譯爲「單體」或「整體」,也就是我們一般典型的大堆頭式的開發系統,它有以下特點:
** 本文同步發表於 FB社群-軟體設計鮮思維 **
所以,微服務的定義是什麼呢?(What is Microservices)
它其實是一種架構設計的風格 (architecture design style) ,並沒有一種很絕對嚴謹的定義,要說較通用的說明,可以參考如下:
「用以描述將系統依據業務能力 (business capability) 分解為多個可獨立 (independent) 被建構 (built)、部署 (deployed) 與延展 (scaled) 的服務 (services)。」
微服務的表現 (represent) 可以參考如圖所繪製的醫療業務領域 (health care business domain),這是可以建構微服務系統的最佳應用。
** 本文同步發表於 FB社群-軟體設計鮮思維 **
這裏藉由一個「放入購物車」的極小型功能案例,並利用 UML 各面向的設計圖,來表達微服務 (Microservices) 的架構規劃與設計的呈現樣貌。下列是幾個主要設計面向的設計圖 (並非是全部) 可以參考。
利用 UML 使用案例模型 (use case model) 與系統循序 (sequence) 圖表達「放入購物車」的系統功能與主要實現程序。
** 本文同步發表於 FB社群-軟體設計鮮思維 **
最近在線上輔導了一位 技術職PM 結構設計的實現 (Realization)議題,他傳給我 DDD 的架構圖,覺得在「Domain Service」與「Domain Model」的責任界定上,觀念不是很清楚。
嗯,其實這所謂的 DDD (Domain Driven Development) 架構圖根本就是典型 3-tier (Presentation-Application Logic-Data Source) 分層結構呈現爲圓形的剝洋蔥層次而已,越是內層 (Domain Model) 越代表爲系統的核心。
工程師從這張圖往往會認爲「Domain Model」是最重要的核心觀念。是這樣沒錯,但對以「需求爲導向」的專案開發性質,它卻反而沒那麼重要!況且結構設計的基礎功夫要很紮實,封裝-介面-多型 諸多「虛」的設計觀念確實能充分了解並能整合活用,沒有花上 5-10 年以上功夫,是不容易應用在現實的系統開發上的。相對於此,「Domain Service」對現實的專案開發可是更切實際,且結構設計上的觀念也會比較容易入手。
ECLIPSELINK_HOME = <INSTALL_DIR>/eclipselink。