＊＊ 本文同步發表於 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，特地利用週末時間到我家附近，請教我關於他利用 UML 所繪製的設計圖問題。相當認真，所以我很願意陪他一同討論軟體相關議題，順道一同在肯德基吃午餐。總共花了約兩個來小時吧，該學員還要去參加他的讀書會，真是有夠認真啊，不過起碼有討論出一個比較具代表性的使用案例其實現的主要程序描述。
畫出來是否正確或合理與否是一回事，至少他肯利用 UML 表現出他的設計思維就很值得肯定，這才有機會可以指指點點與討論的。
他只畫了使用案例圖與某一結構設計的類別圖，因爲有公司機密問題，這裏就不方便貼出他的原稿。我只就他的設計給予一些建議與修正，並利用他在 Mac 所使用的 UML 工具繪製出來。
最近在整理原來實體課程的教材內容，準備移轉到線上教學平台上 (我的第一個線上課程應確定爲「活用 UML 體現軟體設計思維」)，首先考量的應該是國外最大的教學平台 - Udemy。
實體教學與線上教學肯定是截然不同的方式，前者重於與學員的「互動」，甚而需「因材施教」，動態改變課程內容；但後者並沒有可與之互動的觀衆，所以事前錄製的內容與呈現方式，以及每一個單元的主題與目標，就要相當明確了。
最主要的呈現方式當然就是視頻錄製，並可以使用如 Powerpoint 的簡報作課程大綱與內容說明，另外涉及到開發工具的操作等，就需要螢幕錄製操作步驟。每一個視頻單元，據我大量查看 Udemy 衆多課程講師，大都爲 5~10 分鐘左右，單元主題要能切中該視頻內容，可以是很通俗的命名。
與我實體課程規劃大綱的方式最大的不同是，Udemy 課程大綱主要只有兩層：Section 與 Lecture。
Section 比較像是章、節的概念，而 Lecture 與傳統書籍大綱內的小節觀念可能不大相同，它要呈現的是一個講課、講座、講稿這樣的概念。
Section 比較容易界定，一個「章/節」的目標 (objective) 明確就沒有問題。而 Lecture 我是很不習慣，主要就在於要配合視頻 5~10 分鐘內的長度，所以以前的小節觀念，需要分割或合併，但要給予一個清晰的 Lecture 講座名稱，有時沒想像得簡單。
＊＊ 本文同步發表於 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」對現實的專案開發可是更切實際，且結構設計上的觀念也會比較容易入手。
