Gelis 技術隨筆-部落格

軟體架構設計：有『題』（二）- 為X宏網路售票系統加入 API First 網站 前言 在上一篇文章〔 軟體架構設計：有『題』- API 設計原則以『線上售票系統為例 〕裡面，我們幾乎在 LINQPad 上完成了一個線上購票的雛形，而這一次，一個部分是我們會再持續的建模的過程中補足一些上一次的缺失部分、第二部分則是加入網站設計部分，而這個網站會使用先前我在某客戶端所開發的 API Framework 框架為基底來設計，除了完全支援 >NET 6 外，這個框架封裝的許多在 Clean Architecture 裡屬於 Infrastructure 的部分，包括 【Role Security Access Controll Layer】與【Notification】以及【Log】等功能，更細部的部份我們下面再來談。 持續的建模 針對上一次，我們在X宏網路售票系統中用 UML 所呈現的 DDD 的 Domain Modeling 與 對照 Scenario 可以發現幾個小缺失。 (1). 加入 ShowTime 的 ValueObject (2). 建立 SeatReservation 實體的 Create 方法 (3). 調整 ConcertVenue 音樂會場地物件實作 另外，也針對 Application Services 的 購票作業 Reservation 方法調整程式碼邏輯，因應票卷 Ticket 由 Ticket.Create 方法來產生，並需要傳入（訂位代號：ReserveID; 場次：ShowTime） 程式碼中使用的術語，完全參照 Domain Modeling 與 事件風暴 中所精練出的通用語言 (Ubiquotius Language)，以確保程式碼完全可以對照領域模型，建模的過程也完全可以撰寫程式碼，並確保在最短的週期裡完成程式碼的設計與修改。 程式碼調整如下： Domain Layer 的程式碼 public interface IAggregateRoot { } public class Entity { } public abstract class ValueObject { } // 票卷實體 public class Ticket: Entity, IAggregateRoot { ...

軟體架構設計：有『題』- API 設計原則以『線上售票系統為例』 前言 先前，我有篇文章是以讀過【Get Your Hands Dirty on Clean Archiecture】後的心得感想，這本書的中文名稱是：【Clean Architecture 實作篇：在整潔架構上弄髒你的手】，讀完這本書大約是去年 2022/10 月左右，也是我當時在開發 API 新版框架大爆發的時候，書中給我不少的啟發，在配合實際的專案開發的實作經驗 + 框架設計所需要的框架設計便引入六角架構的設計方式，藉以改良原有的舊版的框架，而這篇『 軟體架構設計：無題 ( http://gelis-dotnet.blogspot.com/2022/08/blog-post.html )』中便是以完整的〔六角架構 (Hexagonal Architecture)〕並加以解釋如何在六角架構中落實單元測試 Unit Test，這些都是我讀完書後，實際落實在專案上的實際做法 + 分享。 當時的六角架構 + Unit Test 的範例程式在這： https://github.com/wugelis/AdapterInOutLayerSapmle 上次是無題，今天，我以一個X宏線上售票系統為例子，我們從頭到尾地的，Step By Step 的來介紹，這個 API 售票系統的建置過程，而這裡，我也會搭配 『API 設計原則』一書裡的一些做法，也就是說，這裡開發的 API 會使用 API First 的設計樣式，因為這裡的 API 設計的出發點為該企業、在這個商業模式上所能夠提供之『商業能力』回出發點考量，而不是過往傳統的單一客戶(UI)思維的客製化模式考量，所謂的 API First 是轉向為產品化思惟的導向模式，如此也才能發揮 API 在市場上的價值，這也才是 API First 的思維模式。 需求來源 圖（一）、線上售票系統需求 今天的需求來源，是一個線上售票系統，先前我曾在專案中製作過一個售票系統的雛形，這裡我就拿這個範例來以 DDD 來進行戰略建模，並搭配使用我在新竹顧問時所開發的新版 API Framework 來實作並支撐這個售票系統 API 的 Infrastructure Layer，沒錯，所以言下之意，我們以 DDD 來驅動這個售票系統 API 的開發，所以這裡的 Core...

軟體架構設計：無題 Logo 圖片、六角架構 取自：https://reflectoring.io/spring-hexagonal/ 前言 為什麼叫做無題？因為軟體架構設計是一個相當龐大的主題，也不可能在一篇文章中談完，先前我也曾寫過許多架構設計系列文、包括領域驅動設計 DDD 與 整潔架構 Clean Architecture 與如何在以上的軟體架構為基礎來落實 TDD。 今天，我在以更廣泛與更實務的角度來探討軟體的架構設計，文之中也會搭上我這些年來所設計的框架、Framework 並對上也是這些年後來所讀的相關書籍、像是 DDD 領域驅動設計、Uncle Bob 的 整潔架構 Clean Architecture、還有正在讀的【Get Your Hands Dirty on Clean Archiecture】，這這些書的洗禮之下，也在下面的文章中裡探討缺失、改善的方式，希望對於工作中正在進行架構設計或是正在進行專案規劃，但想要有個架構設計的資料可以參考的程式設計師，那麼或許您可以參考文章中的資料，或許對您有所幫助。 階層式架構設計的隱憂 圖（一）、常見的階層式架構     傳統的階層式架構幾乎伴隨著我們好幾 10 年了，相信讀者不陌生，許多的老系統，包括我在 18 年前在流通業開發的幾個系統、以及後來10年前在X創開發設計的好幾個政府機關的系統也都是階層式架構設計。 究竟什麼是階層式架構？它與更早期講的三層式架構有些不同、比如 Windows DNA 那又是更早的跨機器架構，注意了，那是『跨機器』的軟體架構，像是微軟早期 (DCOM, Distributed Component Object Model) 所以 DCOM 加上 Distribute 表示快機器、而 COM 就是跨行程。 這是早期的分散式環境，套用到現今，許多人想到的 Microservices/Docker.. 微服務等容器環境，這在跨機器的場景非常類似，但是 DCOM 需要完整的 OS 作業環境的支援、而 Microservices 微服務拜後來【VM 虛擬化技術】又再進階到【OS 作業系統虛擬化技術】之賜，使的應用程式可以包裹在更輕量化的容器環境之中，沒有作業系統啟動速度慢、占用系統支援較多等問題、更適合建構需要橫向擴展的 Cloud 雲端運算的環境...

從整潔架構談自定義 NuGet 套件規劃與使用 前言 我們在規劃框架與底層元件時，免不了會將框架的底層元件、像是你 UI 的 BasePage、或者是 MVC 中你自定義的 ViewPage 的 BaseViewPage 又或者是你自定義框架 Framework/Platform 的底層運作包裝成 NuGet 套件供使用該功能的各系統負責人使用，將特定功能包裝成 NuGet 套件再重複使用某些功能時非常的方便，它可能方便到有種魔力，甚至會讓你想將許多功能都包裝成 NuGet 套件以達到重複使用的目的。 問題的發生 現在問題來了，這也是我在客戶端發現到的一個現象。 客戶：Entity Framework 的資料存取功能適合包成一個 NuGet 套件嗎？ 這裡問題來了... 我說：請問這個是指這個套件內容會包含 OR-Mapping 的 Entites/Repository 等內容嗎？😯 如果是，那這個可能不適合包成一個 NuGet 套件。（蝦～什麼？) 客戶接著會說：但是 Entity Framework 本身也是個套件。 我說： Entity Framework 本身由套件來提供這個當然沒有問題，但是你的 Repositories/Entities 以上那已經跟商業有關了？ 客戶更疑惑了：我們在開發框架時，比如說我們的 Business Object 的 Base 不是就是由 NuGet 套件提供的嗎？ 我說：你說的沒有錯！ 但是你現在是把 DataAccess Layer 包成了 NuGet 套件了，當然～沒錯你會認為 DataAccess 算是 Infrastructure 這的確是沒錯！但是這裡的 Infrastructure 應該算是（與你的 Domain/Business 無關的部分）也就是應該不包括你的 Entities 都可以包進 NuGet，那是不正確的。 這時客戶會說，這好難界定阿？老師你說 DataAccess 就是 Infrastructure，但是又不能包進 NuGet，那到底該怎麼做啊？ 🙁 當時，我我很即興的繪製一個【簡圖】來說明（而現在我將這簡圖用 PowerPoint 來畫更專業點的，若想查看原本的簡圖可看我在臉書的 PO 文：https://www.facebook.com/groups/361804...

以領域為中心的：線上房貸申請系統設計 use DDD 前言 DDD 的出現，為的是解決軟體專案開發過程中，不同的專業領域 或 經驗背景、技術專家 與 領域專家 溝通時，你講的跟我講的可能不一樣！？或你講的，跟理解的，跟我想的可能不一樣？... 是的！軟體專案開發最擔心的就是如此，專案會失敗大部分的原因也可能是如此，也因此 2003 年左右，Eric Evans 提出了 DDD, Domain-Driven Design 的思想與概念， 需求內容 圖（一）、案例一：線上房貸申請系統 需求以一個〔線上房代申請系統〕為例，關於這個需求讀者可以參考筆者先前寫過的幾篇 DDD 與 c4Model 的相關 文章 ，是以線上房貸申請系統為例的，而在更早之前我撰寫過一個 決戰 OOAD 的線上課程 ，課程中我們只是以基礎的 OOAD 並搭配 MDA 為出發點進行設計，現在，我想改以 DDD 領域驅動設計的方式重新設計這個線上房貸申請系統，上過此課程的學員也可以重新再練習一次，並跟著同時學習 DDD 的設計方式，因為同樣以 MDA 角度為出發點來設計。 領域敘事 （Domain Storytelling） 這邊我習慣以領域敘事來描述領域專家的的需求任務，原因除了團隊與個人習慣外，無其他特別因素。 圖（二）、顧客線上申請房貸的領域敘事 DDD 與軟體架構設計 DDD 其實不管軟體架構設計的，原因稍後會提到，DDD 大致分為兩大部分，也就是『戰略（Strategic）』、『戰術（Tactical）』，戰略的部分主要在解決領域需求上，不同角色間的協作與溝通，盡量能說出共通語言，或者建立共通的語言，也是 DDD 一直強調的 Ubiquitous Language 通用語言，並以此為基礎來建立領域知識，因為不同領域（銀行／流通業／金融業...）總是有個領域的專業術語，而在分析解決商業需求時，使用大家都能懂沒有隔閡的語言來溝通相當的重要。 圖（三）、解決領域需求與建模 線上房貸申請系統的領域模型 在本篇文章中，我加入〔額度利率試算〕這個 Context，原因是它經過需求提煉的過程中發現是可以獨立開來的 Context， 因此直接拆另一個 Bounded Context，而根據需求，需求中銀行顧客可以到線上房貸申請首頁，使用網銀帳號或初次申請進行簡訊驗證後方可填寫...

圖、以線上房貸系統為例的 Domain Model 領域模型 那天，在 DDD 分享了一個主題［實踐 Clean Architecture（實作高可用性的軟件架構）］，由於講得不好而招致 Teddy 的批評，還寫在部落格上，既然你都可以指名了，那我也不怕指名，今天，我就針對上次未講完的部分再來做個補充說明，也就是我怎麼在 DDD 裡實踐軟體架構設計時，怎麼樣具備高度延展性？如何真的做到高可用？在筆者的專案經歷裡面，也常常遇到類似的情況，比如新增店鋪或修改店鋪邏輯時不影響原有核心架構？或者是我依照使用者修改信託的申辦邏輯時，如何在修改的同時，又不易動到原有的已經申辦的會員後台管理系統？在還沒有 DDD 的思維介入時，將商業邏輯服務化是普遍的解決方式，筆者當時的跨平台 Web API Framework 框架便是要解決這樣的問題，因為我將商業邏輯變成可抽換的 Component (Business Object)。 補充：可抽換的商業邏輯架構可參考我公開的 NuGet 套件 Easy Architect Framework Ok, 如果切換為 DDD 以領域模型為主的思考模式差異會有多大？我們以那天，我在『實踐 Clean Architecture 實作高可用性的軟件架構』中所使用的［線上房貸申請為例］，需求如下： 需求1： 銀行顧客，或是非銀行顧客可到網路銀行線上房貸申請首頁，使用網銀帳號或簡訊密碼進行身份認證後，可填寫「基本資料」與「貸款資料」， 非銀行顧客須先填寫「基本資料」 課程中，我以 C4 Model 來開場的用意其實是要描述軟體架構 如何高可用 ？在 DDD 裡面，我們著重在領域核心，我們都不建議一開始就寫程式，而是先了解全貌，至於全貌是什麼？許多敏捷的概念我這裡不再祥提，有興趣的讀者可參考相關文章，沒了解全貌而貿然的設計 Domain Model ，即便是 DDD 我認為也會提高失敗的風險［可參考先前文章： DDD 中為人所忽略的『軟體工程』與『工程實踐』方法 ］， 我們在談理論時，最終就是要貫徹到實作中，而 C4 Model 提供一個對應到實作的一個很好的方法，搭配 Clean Architecture 這對於真正的高可用的軟體開發有非常大的幫助，因為在 Domain Model 變更時，我能夠最快的調整程式碼、而重點 在於容易釐清模組之間...

圖（一）、Bounded Context 前言 先前筆者撰寫許多關於軟體架構相關文章，有敏捷的軟體架構、也談過 Clean Architecture、包括我自行設計的跨平台的 Web API Framework 框架 Easy Architect Framework 等等，不管談論哪一種都圍繞在軟體本身的高可維護性、擴充性等議題，但常言道，能力（技術）要在更往上一步就得忘掉現在所有所學的東西，不要被現有學習的東西所牽絆才能更上一層樓，金庸裡的張無忌也是忘掉九陽神功與乾坤大挪移後也才瞬間學會的張三丰的太極拳法，因為長久以來你都使用瀑布開發方法，專案也都能成功結案，看似當然也無問題，因為剛好都在你熟悉的產業即便設計完才做開發也不致有你非預期情況會發生，因為你已經非常熟悉改產業、但當遇到其他產業時，專案實作過程中便會遇到需求認知錯誤、錯估範圍、部分打掉重練、時間浪費、人力不足、現有架構無法發揮功用、時間到最後便不足而最後導致專案失敗的窘境，這就是熟悉一種開發方法時，久了就會無視其他的開發方法，就像 OOAD 非常熟悉，解決各種軟體開發大小問題都會迎刃而解，系統開發 90% 都可以在經驗種解決，最後也會無視訪間流行的它種開發方法像是 DDD 等等，但是當你遇到 cloud 環境、Microservices、或者 Serverless 環境的時候，你不再是以單就以物件的角度來思考、在分散式環境裡，有些是違背物件導向思考方式的，你可能是使用流程角度來思考，領域驅動開發的概念也應蘊而生。 DDD, Domain Driven Devlopment 領域驅動開發 近幾年來、DDD 領域驅動概念不斷的蓬勃發展起來，這是因為 Cloud/Microservices 議題不斷的是重視，傳統的 SOA 已經慢慢不敷使用了，如果要應付更大量的服務需求吞吐量、不太可能像傳統架設單一伺服器來解決，在領域驅動裡使用 Bounded Context 的概念來分界模型 Domain Modeling 的應用範圍，讓團隊成員在進行合作時什麼該保持一致？Bounded Context 與其他的 Bounded Context 該如何構通？以及『上下文如何關聯』有一個明確且共通的術語 Ubiquitous Language，這共通的語言可以是某一段程式碼、或者是團隊的組織、軟體系統機的介接用法、或者...

圖（一）、LOGO: 基於 Clean Architecture 改畫製的 3D 立體圖形 前言 其實，我應該不止一次討論過這個主題，關於 Clean Architecture 的 Plug-In 的軟件架構，在〔軟體開發之路〕或先前所開的實體課程〔跨平台的 Web API Framework 框架設計〕中討論過、也實際帶著學生實作過這樣的架構。 何謂插件式的軟件架構？ 圖（二）、從裝置定義 IDevice 介面來演示 Plug-In 插件式軟件架構 如上圖中，不管是 Quantum 硬碟 還是 Pioneer DVD 都是透過 IDevice 介面來實現硬碟 IHardDisk 的主要功能 或者是 透過 IDVDDeive 來定義 Pioneer 光碟機必備的功能，然而最好能夠透過 DI 注入實作，所以系統的靈活度非常高，組件頂多對介面相依，實作輕易的被抽換。 或者是利用 AOP 模式賦予驗證機制或使用匿名存取，優點也是可抽換性非常高，異動原有功能也不須異動到原有的程式碼。 圖（三）、透過 AOP 賦予驗證機制 先前，我在曾在軟體開發之路裡 PO 過關於在 Clean Architecture 的圖形中，在架構圖的右下角的 Use Case Output Port/Use Case Input Port 到底指的是什麼？而且事後並不只一次也有其他的學員或朋友問我相同的問題，而這其實可由 MVP／MVVM 來講起，為什麼呢？ 圖（四）、The Clean Architecture 這其實可由 MVP／MVVM 來講起，為什麼呢？因為在 Clean Architecture 或是更早期的【洋蔥式架構】或【六腳架構】都是由外圈而內相依，內圈可獨立存在。 但問題來了，如果你用 MVC 或是 MVVM 來實現 Clean Architecture 軟體架構的時候，雖然 MVC 本身職責分離，由 Controller 負責協調 View 所需要的 Data，但 View 與 Model 仍然有某種相依性程度在，也就是說，仍然有可能因為 View 的改變而牽連 Model 必須跟著改變，而這違背 Clean Architecture 原本的精神。 好....那所以，該怎麼辦呢？就是在 View 與 (Model/Use Case) 之間，加上一個 P...

這次，於 2019/05/05 受新竹敏捷社群總舵主柯仁傑的邀請，在新竹敏捷社群我分享了一個關於 您的軟體架構夠敏捷嗎？ 的主題，在這個主題當中，我分享了我個人早期多年在專案開發上的系統設計相關經驗外，與最近這五年執行顧問時，替企業規畫與設計軟體架構相關經驗的分享，過程中，與觀眾有幾個共鳴點待我在下方娓娓道來。 軟體的快速交付≠有價值的交付 課程一開始，我提到了在十多年前，我曾待過一家軟體公司，在這個環境中我們嘗試創造出一個 0 缺陷的軟體架構，詳細的內容我在上一篇文章【 敏捷的軟體架構設計：可擴展的軟體架構 】裡有說明，這裡不再重述。 接著，我提到了現在也是開發流程+開發方法百花齊放的年代，只是 Agile／DevOps 特別為人所知而已，但在這個混亂的年代分常容易讓人無所適從，尤其時初學者，因為你所處的環境有可能已經追不上大環境中的變化與改變的速度了，但是你卻還是有很多東西要學，對吧？我的意思是，最讓人無所適從的倒不是技術的推層出新，慢慢的反而是到底是改怎麼做才是正確的？這部分我們以下在詳盡說明。 先前我曾聽過某大廠的 App 能夠在一天之內交付 20 ~ 30 次的版本，這對一家軟體公司來說，維運與開發之間必須非常的運作與整合完備情況下，再加上工具的熟悉度極高，才有可能將 CI／CD 持續整合+自動化部暑到如此境界 ，有許多軟體開發商無不卯足全力渴望達成此境界！ 但是據我所知，大部分大型購物網站、或者對外的訂票系統，事實上，他們在實務上只需要一天上一個至兩個版本便足夠了！ 如果您需要在一天之內上 20-30 次版的話，通常代表著您的開發流程可能是出了問題，比如：團隊與 User 可能存在著隔閡／開發人員或小組之間沒有共識+不清楚需求就冒然的修改程式碼… 等等。 我在這邊請大家思考另一個面向問題，就是，軟體公司究竟想要什麼？做專案+產品想要的是什麼？就是【獲利】！對吧？做這麼多，改變這麼多，去了解敏捷是什麼！最終目的，就是要賺錢，但是要賺錢，就得先思考如何【獲利】呢？因為你們在進行系統開發時一定常常遇到下面問題： 測試總是花費許多時間？ 軟體的修改總是牽一髮動全身？ 無法掌控的技術債？ 失控 的技術債？ 需求確定後，才可以開始寫程式？ 架構設計完成後？才可以開始寫程式？ 對了，看到這裡答案就呼之欲出了，公司要賺錢，就是要將『成本...

圖片來源： https://www.magzter.com/articles/488/256119/5a2a9554df1c0 什麼都要敏捷？ 近年來，敏捷概念幾乎已經深入人心，不光是軟體業談敏捷，慢慢的可以看見各行各業也在談敏捷的思想，前幾次的 Agile 活動裡，不再像以前一樣，只會出現軟體相關產業的面孔。為什麼敏捷思想開始深入人心？其實是因為『變化』不只存在於軟體產業，要面對未來、面對變化、面對挑戰，唯有敏捷以對，隨時快速地調整自己，提升自我能力，靈活的面對這些改變，隨時再出發、隨時再出擊。 測試理念的崛起 測試可說是近十年來，發展最快速的軟體開發理論之一，早期的軟體開發將測試定義為軟體開發生命週期裡的其中一個階段，通常後期進行，也就是當軟體完成到某一程度時才進行，但是當軟體完成到某一程度時，也代表著你要對軟體做任何的需求改變、功能的改變、又或者是新增功能，所需的成本可能是非常的高的，這也是傳統的瀑布式開發慢慢為人所棄用的最主要原因之一，因為人們慢慢地察覺到，軟體的『測試』應該與『開發』這件動作密不可分才是，又或者說，測試其實應該算是軟體開發的其中一個動作，而且是非常重要的一個動作，因為經由測試，你曾能夠確認軟體正常運行無誤、經由測試才能確保軟體能夠被交付、符合客戶需求 + 如預期的運作。 而早在十多年前，TDD, Test Driven Development 的大師 Kent Beck 所撰寫的 TDD by Example 一書就已經提到這樣的觀念，先撰寫測試的程式碼 (Unit Test)，在撰寫 Production 的程式碼 從 TDD／ATDD 談傳統 SDLC 的缺陷 在 ATDD 裡提到了左移測試的 V-Model 模型，這個被討論了十多年，只是不幸的是左移這件事常常被誤解成只是將測試移轉至左側，而忽略了由上而下的測試進行。然而，當然，許多的軟體開發者也都知道，在軟體開發生命週期越後期測試所發現問題的時候，修復的代價就越高，這個狀況幾乎可以解釋為傳統 SDLC 的缺陷了，所以，這表示什麼？這意味著在軟體開發生命週期裡應該盡早進行測試才能夠降低這些風險，因為在這些年來因為沒有盡早測試而產生的問題如下： 測試人員可能沒有參與軟體的初始規劃，通常導致測試對系統了解有限+最後分配給測試的資源又嚴重不足 許多需求，架構和設計缺陷都沒有再一開始被『發...

前言 前一篇文章中『 從使用者需求、談架構設計 』，筆者以一個房貸線上申請系統的例子，關於一個從使用者需求、來談架構設計的一個比較實際的例子，當時，筆者以 UML／OOAD 常見的循環星型分析法，帶著各位由系統分析開始、如何串聯到系統設計、並解釋因為從系統設計開始，便可牽涉到 Platform/OS/Framework/程式語言 等等，而在 UML 這裡也有模型驅動架構 MDA (Model Driven Architecture) 可以補助，課程中，我也利用的這樣的概念，將 Domain Class Diagram 帶入細部 Class Diagram 分析時，拆解為兩塊，一個是 BO (Business Objects) 另一個是 VO (View Objects)，接著，並實際的撰寫程式，並實作出最小可行性產品。 在今天的這一篇文章裡，我將利用在 Clean Architecture 書中的一個整潔的軟體架構的概念，將我三年前所設計的 EasyArchitect Framework 來做一個應證，從頭來探討軟體開發、從需求面開始、你的需求大方向的掌握度其實會決定你的架構設計的方向性是否恰當、符合所需、不是過度設計的架構。好，我們接著往下看。 需求掌握度 圖（一）、Impacts Mapping to User Story Mapping 圖片來源： https://www.slideshare.net/chassa/2014-0618srdimpact-mapsstorymapsen 為什麼談需求的掌握度？訪間，許多軟體開發方法告訴你的大部分是，何時該做什麼、那些角色該關注什麼？有哪些會議？什麼時候招開？該注意什麼？以敏捷創建使用者故事地圖（User Story Mapping）來說，它敏捷需求規劃中的一個流行方法。用戶故事地圖可以將你的 Backlog 變成一張二維地圖，而不是傳統的簡單列表。用戶故事地圖可以讓你更容易看清 Backlog 的全貌。這概念真的非常好，因為它幫助你有更好的進行疊代的增量式開發，同時確保早期的發布，可以驗證整體架構和解決方案，為傳統的開發計劃提供了一個更好的替代工具。 且創建 User Story Mapping 可以有七～八個步驟，因為篇幅關係我不在這一一說明，第一個步驟是招集 3-5 對產品熟悉的人一起討論，並讓每個人在便簽紙...