＊＊ 本文同步發表於 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」對現實的專案開發可是更切實際，且結構設計上的觀念也會比較容易入手。
＊＊ 本文同步發表於 軟體設計鮮思維FB社群 ＊＊
上星期我在教授 TDD.NET 測試驅動開發課程。其中有位學員分享他們公司會計系統的部分程式碼 (沒有機密性議題)，想知道這該如何撰寫單元測試 (Unit Test Code)。
我先用 EA (Enterprise Architect) UML 工具掃描程式碼反轉為 類別 (Class) 圖，老天！數百個 Windows Form (每一個 Form 他們稱為 Report) 全連接到一顆共用的 DB Manager，封裝了基本的 CRUD 行為，再存取資料庫。剛掃進來時還真嚇了一跳跳，那個 Form 的連線，有如積體電路般密密麻麻的共同連接到如同就是 CPU 地位的 DB Manager！
這肯定就是典型技術人員的傑作，用許多稀奇古怪的實作方式，讓所有的表單 UI 程式，傳進來 SQL 敘述，然後再去存取資料庫。看似方便簡單，但這顆萬用的 DB Manager 已經被約束了特定的實作技術與特定的資料庫，所以當然無法抽換，原來他們使用 ADO.NET 的連線，現在是不可能換成 Entity Framework；不僅如此，內部程式碼的擁腫肥大，當時的技術人員一離開，幾乎達到無法維護的地步。
＊＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊＊
關於 POC (Proof of Concepts)的說明，可參考：「淺論架構的 POC (Proof of Concepts)」。
關於系統結構設計 (system structure design)，個人把它分為兩個構面來看：巨觀與微觀 (Macro/Micro View)。
巨觀結構設計是基於現實系統的分散議題－展示層 (如 Web UI)、永續儲存機制 (如 關聯資料庫)，所提出核心業務邏輯應不相依於特定實體元件與實作連結技術的解決方案。這裡推出最實用具應變與可重構的實體分層框架－Enterprise MVC (Model-View-Control)模式 (並非是廠商針對 Web 端提出的 Web MVC 技術)，讓系統主結構 (業務邏輯/資料存取)有效隔離展示層與永續儲存機制的直接耦合 (coupling)。
微觀結構設計則是傳統物件導向所談及從領域概念模型 (domain conceptual model)，導出到軟體物件與資料模型 (class/data model)。這裡使用的分析設計技能包括了運用 Peter Coad 的「交易模式 (Transaction Pattern)」與 GoF 四人幫的「設計模式 (Design Patterns)」。有別於古典OO 一開始就要求較完整的設計 (太過理想化)，現今系統開發則更為務實－運用重構 (re-factoring)的技巧，持續逐漸地重整系統，效果即是簡潔易維護的程式碼 (clean code)。而伴隨著重構的一項必要機制與紀律就必然要求一開始就要撰寫單元測試程式碼 (unit test code)。
上述兩個構面是互補的。軟體主結構一開始就不會實作於特定的UI/資料庫端，以最純淨的 POCO/POJO (plain-old CLR/Java Object)物件來實作，如此才有機會得以實施後續的重構，而重構則取決於某一功能的複雜度與價值來評估，進而創造出系統整體的再利用價值。
本文著重於巨觀結構分層界定與實踐，藉以驗證巨觀結構 POC 的可行性。觀念說明利用 UML 設計圖表現巨觀分層結構；實作則各以 C#.NET 與 Java/Spring 實現一個極小的案例來貫穿整個系統的分層結構元素。
C#.NET 採以 ASP.NET Web MVC 與 E-F (Entity Framework)實作；Java/Spring 則採以 Spring Web MVC 與 傳統 JDBC (也可改 Hibernate Framework)實作。兩者會再佐以 UML 循序圖 (sequence diagram)，來輔助解讀案例執行時物件之間的互動合作關係。
把主要分層結構當成元件 (component)看待，以界定各元件主要的責任 (responsibility)。
