Gelis 技術隨筆-部落格

軟體工程師 - 成長的 10 個階段 前言 先前，我在 Study4 小聚 #6 分享的一場關於軟體工程師 & 架構設計的養成之路，在該議程中，我分享了軟體工程師的 10 個階段（你的階段如有雷同、應該是...純屬巧合。XDDD） 哪 10 個階段？ 我將軟體工程師的成長依序分為 10 個成長階段，因為隨著技能的提升，你該擴充的 不會只是只有軟體開發技術，溝通與協作能力尤其重要 ，也像是『康威定律』中所提到的， 你的軟件的設計 & 或系統設計本質上反映了企業的組織機構。系統各個模塊間的介面的設計，也反映了企業各個部門之間的信息流動和合作方式，這些技能再進行軟體架構設計時也息息相關 ，團隊在進行模組設計時需要頻繁的溝通，這些、都是是否能將軟體做好的關鍵因素。 如 Logo 圖片，我依序說明每個階段的成長歷程。 1). 初始開發階段、熟悉 Programming/Developer 階段（PM/PO/SD 給規格後加以實作出來），並能夠藉由 模仿 來學習。這是剛進入軟體產業的學習階段。 2). 此階段代表已懂得透過重構來讓程式碼有基本的可維護性 、已能熟用 DRY (Don't Repeat Yourself)，進入這個階段代表已經有基本的程式語言的基礎， 應付 Programming/Developer 日常 工作 上的需求基本上沒什麼太大的問題。 3). 這裡的專案收尾代表對於專案開發已經有某些程度的認知、掌握度。我所提的掌握度在於了解『技術債』的產生緣由 與 危害，在 Programming/Devloper 層面懂得透過 S.O.L.I.D./Design Patterns 解決問題 並 開始能夠 自我學習 + 自我成長 。 4). 我這裡用『紀錄』 代表能運用所學 + 將使用者需求運用 〔邏輯思考〕 與 〔抽象化〕 轉化為程式碼 + 並能 自我成長 將經驗保存下來。我認為這是跨越只是（寫程式／實作）進入另一個門檻的重要經驗與歷練。 這個階段花費的時間會較長一點，時間長短取決於個人歷練、經歷、學習的環境與工作內容。 5). 此階段含括上面所有技能，並能夠與〔團隊〕和〔客戶〕 溝通 與 協作 、並產生出〔產品〕。而所謂的協作代表，不只自身技術所長能應付本身開發工作工作所需，亦能帶領團隊解決軟體專案的大小事務、也能夠替...

學習 Event Storming 的一點感想 前言 近幾年，工作坊非常流行，也順便分享我的感想。 先說明，Event Storming 的初始概念非常棒，小編也從不排斥各種軟體開發的方法論與流程，但在接觸了 Event Storming 後，對於軟體開發的初心者來說，當中可能有兩個小陷阱。 Event Storming 最近一直在看 Event Storming ，也曾聽聞有人說用事件風暴來取代 UML Methodology，但 UML 充其量只是個 Methodology，你又不是導入 RUP，所以我特別強調這個 XDD，那麼..言歸正傳、的確，事實上我是同意一項軟體產品所需要的領域知識往往是跨團隊的，沒有任何單一團隊可以掌握它的全貌，但要如何媒合不同背景知識的人做有效溝通非常的困難，所以即便是求討論會議除了需要各利害關係人參與之外、客戶能加入討論更能釐清許多需求認知的問題、避免走過多冤枉路，UML 各個圖形的繪製也必須是團隊一同繪製、而不是單一個 Member 來繪製，因為對於商業流程的理解、包含名詞的使用、團隊有共識需使用客戶端的專有名詞與語言。 看完 Event Storming 我倒認為重點不在於 Event Storming，透過 Event Storming 確實很容易找出商業流程的核心價值、風險、與機會，但注意了，我覺得這裡有一個小陷阱就是，重點是在於〔團隊 與 多方角色 所進行討論的『這一個過程』中，便利貼只是風暴過程中的工具而已〕。 我們進行需求討論的的『多方討論』即是邀請任何有興趣的人、也不用限制討論範圍，但這裡還有第二個陷阱，在討論特定功能流程 Process Modeling 時，當你有了 Command、Event、Actor、System、Policy 或 Read Model... 等，準備進行 Software Design 軟體設計時，這裡我非常推崇 Aggregate 與 Bounded Context 等概念，因為這算是 OOA(Object Oriented Analysis) / OOD(Object Oriented Design) 的缺陷部分（OOAD 不是沒有缺陷、近期學習 DDD 時我發現可以補足 OOAD 不足之處），但我要講的第二個小陷阱是，當你在進行 Software Design 時，仍...

DDD 領域驅動設計文章導讀 pictrue from:https://zh.wikipedia.org/wiki/%E7%BB%9F%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AF%AD%E8%A8%80 前言 其實我接觸 DDD 的時間並不長，我進行專案工作的時間幾乎 20 個年頭的我，接觸與真的實務應用 DDD 也不過是 2019 年底左右，當時 Containers & Microservices 正盛起，連帶的讓 DDD 的開發方法論在台灣萌芽（雖然 DDD 與微服務沒什麼直接關係、許多是商業炒作）包括微軟在推的 Docker 與 運行在 Cloud/Azure 的 AKS(Azure Kubernetes)等等，都有許多官方 Docs 文件說明著如何運用 DDD 的設計導向微軟的微服務模型、或是『使用 .NET 設計與實作微服務模型』等等，不過當然，這還是沒什麼直接的關係XD 只不過，你要弄清楚的是，DDD 不是萬靈丹能夠解決你將現有系統無痛的上 Cloud 的 Microservices 環境，而是，透過 DDD 的 Bounded Context/Context Map 概念，可以幫助你切割現有單體式系統中服務的商業體系、像是如何切割 Context、各 Context 之間如何(通信 / 溝通) 等等。 以下，我將先前所有撰寫過的 DDD 相關的文章，依照學習上的順序，為讀者們做個導讀。 學習 DDD 其實有些門檻，以下我列幾種情境供各位參考：  一、寫程式 1-2 年、物件導向基礎還在學習者  二、寫程式超過 5 年、物件導向已熟悉（包括：SOLID, GoF Design Patterns）  三、［延伸第二點］也接觸過 OOA/OOD 並有過專案開發經歷過完整分析設計流程 + 抽象化能力（若有接觸過分析階段的 UML 更加分） 四、已經熟悉 OOA/OOD 與 OOP 也具備上述三點條件，並實作過 Clean Architecture 為什麼第三點我要特別提到『若有接觸過分析階段的 UML 更加分』呢？ (1)分析階段的 UML 是什麼？(2)以及為什麼一定要使用 UML？ 我先回答第二個問題，UML 只是眾多分析階段圖形的一種，像是 BPMN, SysML 也都是業界的商業...

  今天重看這本電子書：【Patterns of Enterprise Application Architecture】 我分享一下我以我現在的觀點重讀過這本書的觀點，因為上一次讀這本書已經 10 多年前，當時對於許多實作內容其實懵懵懂懂也都只是在專案上使用，由於當時專案非常忙碌（幾乎每日加班到晚上12點趕最後一班捷運 XD） 對於書上提及的 Patterns 也沒太多時間去深入探討與理解。 今天，我就以我現在的經歷、對軟體開發技術的認知 + 實作經驗 來重讀 與 介紹本書籍。 我一個一個章節來為大家分享讀書心得： Chapter 1 Layering 對於『分層』定義不熟悉的朋友，建議熟讀這章節。 Chapter 2: Organizing Domain Logic 前面幾章就屬這章節最有意思，文中提到隨著商業邏輯的越來越複雜，不管你使用哪一種軟體架構當你要添加功能其實就越來越困難，因為很難有一種能夠衡量領域複雜性的方法存在（很有意思、這到目前也都還是如此）不過在我最近讀了 DDD 相關書籍後這部分有所改觀了！ Chapter 3 Mapping to Relational Database 這個章節說明一般應用程式存取關聯式資料庫常用的策略，如果您是剛入門不久的 Developer 真的建議好好讀這篇。 這裡提到早期的大型主機後來不盛行被SQL取代的原因，開發人員不夠了解SQL查詢與底層效能索引調教之間關係，導致後續許多問題的發生。接著，就是一些實務上操作 SQL 一些策略，像是一個特定領域 Domain 就與該特定領域 Table 互動、另一種，是 Customer 應該隔著一層 Mapper 才操作 SQL、而不是直接操作，Customer 應該只負責特定領域，不該了解太多 create/load/save 的細節。接著，就是我很熟悉的 O/R Mapping 其實、這章節對我來說並沒有學到新東西、因為我現在實作遠超過這些。 Chapter 4: Web Presentation 在現在 Web 蓬勃發展的現代來說，這個章我就真的沒學到什麼東西，書中使用的 技術 有些老舊了，對基本 Web 不熟悉者可以參考看看。 Chapter 5: Concurrency (by Martin Fowler and David Rice) 本章節也建議開發者一定...

Problem space solution space (問題空間 與 解決方案空間)   圖片來源：https://hbr.org/2013/09/when-youre-innovating-resist-l 印象中 ，好像在哪裡曾看過一篇文章，但印象不深刻，是說著 Problem space and solution space (問題空間 與 解決方案空間) 我的工作的時間非常長，長時間下來，其實一直專注在解決客戶問題，而最近幾年我發現一件事情就是，『一個問題通常不會只有一種解法、你永遠不會知道這個問題未來會不會有另一種解法？』 一直以來，我們常關注在客戶要解決的問題，而忽略了『問題』 與 『解決方案』是完全獨立的個體，是我們自己將這個解決方案 "強行" 掛在這個 "問題" 上頭，但這是對的嗎？對客戶來說，是解決了問題，但長遠來說，不一定。對企業經營來說，對其他公司來說，或對你自己的發展來說都不一定，因為個解決方案框住了這件事情的本質。 我後來有一個體認就是， 一個問題永遠不會只有一種解決方案，有時，『忘掉所有的解決方案，並回歸到問題的本質』，有時我們才能夠跳脫出原本的框架，重新的思考問題的本質 ，因為問題本身可能其實與技術完全無關， 【問題空間 與 解決方案空間】的關係這就像是我們在做系統分析時，【商業需求 與 技術】之間的關係一樣，兩者本來就不搭嘎 ，同樣的商業需求，你可以用各種技術去實現，完全不需要被 "技術" 而限制住了你的思考，這也是我最近學習 DDD 領域驅動設計後，又在這方面產生了更大的體認。 因為 DDD 的 Problem Domain 也是希望我們關注在這個商業需求的問題本質上，而不要被外在的不相關（工具 / Solution / Others..）等牽絆而影響到我們去理解這個問題的本質，其實 DDD 就是在教我們這個概念，而 Bounded Context 與 Context Map 也是在告訴我們不要將兩個不搭嘎的問題牽扯在一起，這也會影響你最後如何套上正確的 Solution。 這算是最近學習 DDD 領域驅動設計的一些些收穫吧！ 參考資料：  https://www.packtpub.com/product/hands-on-domain-driven-d...

Blazor 如何處裡狀態？（三） 前言 先前分享過幾篇關於 Blazor 的狀態保存，先前關於狀態保存有許多錯誤的地方，比如：其實 .NET Core 本身就有 IMemoryCache 或者是 Singleton 物件可以做到『狀態保存』這件事情。所以，本篇再次快速地向各位尋覽一下所有關於 Blazor 裡狀態如何保存這件事情。 .NET Conf 2020 的演講內容 小弟在去年的 .NET Conf 2020 的分享： Blazor Components 開發實戰 裡面也重新的介紹 Blazor 的狀態保存，當時我分為五種： 上圖、取自我在.NET Conf 2020 中的投影片： Blazor Components 開發實戰   今天我們來介紹我在  Blazor Components 開發實戰  的 Slide 上講到的幾種方式：  有興趣的參考上方我在 .NET Conf  2020 Taiwan 所分享的 Blazor Components 開發實戰 的投影片。 （一）、資料庫  （二）、協力廠商支援 Cache（Redis, Others…）  （三）、保存記憶體內容狀態 (.NET Core)  （四）、Browser Local Storage  （五）、URL 底下，筆者以範例程式來說明這幾種的用法、差異的比較。 （一）、資料庫 資料庫的做法，其實我相信俗果可以用資料庫，保存哪有什麼問題 XD，如果可以用資料庫，相信這大家都很熟，我們就... 略過吧？..（咦？） （二）、協力廠商支援 Cache（Redis, Others…） 在協力廠商的支援裡，除了 Redis Cache 外，訪間其他種類的 NoSQL 產品，像是建立分散式資料庫的 Cassandra、Hadoop 等等的 key-value 形式的巨量系統其實也都可以算在內的，而這邊我們以常見的 Redis 來介紹基本的用法。 (1). 首先建立 Blazor Server 專案 (2). 建立 .NET Core/.NET Standard 類別庫專案 這裡一樣套用部分整潔架構 ( Clean Architecture )，為什麼說...

以領域為核心重新設計的線上房貸申請系統 use DDD （2） 前言 在前一篇文章： 以領域為中心的：線上房貸申請系統設計 use DDD 中，筆者簡單的介紹一下以房貸線上申請為例子的的領域模型如何繪製、以及用一點時間將領域模型撰寫成基本的程式碼骨架，現在，本篇文章將接續直播的內容持續的調整程式碼。 Visual Studio 2019 的 .NET 5 的整潔架構骨架 這裡也同步的調整一開始的設計，也就是 Repositories 的擺放位置，一開始我是放在 Domain Service 也就是領域層，有網友發現表示以依賴反向來說，應是由 Application Service/Use Case Layer 來存取 Repositories，雖然 Entity 可以透過 Factory 來產生實例，但是 Entity 必須透過 Aggregate 來無持資料的完整性，但調用 Entities/Value Objects 本來就是 Application Services/Layer 的責任，所以 ICustomerDetailRepository 放置在 Application Seervice 是比較合理的，因為本來就是 Application 來操作 Aggregate Root 並維持資料的完整性。 圖（一）、透過常見的依賴反轉來解決問題   圖片取自：Clean Architecture 無暇的程式碼 - 整潔的軟體架構設計篇 因為 Entity 本來就在 Domain Layer，為了領域邏輯的獨立性，並不應該直接相依 Repository，外部調用 Domain 需要領域邏輯來操作得依靠 DIP 即可解決該問題。 另外，補充說明，就是其實以『依賴反向』來說，Clean Architecture 的 Aggregate Root 要封裝 Domain Layer 的多個的 Entities/Value Objects 的操作來講，將 ICustomerDetailRepository 放置在 Application Layer 這是正確的。 怎麼說呢？以 Clean Architecture 整潔架構一書中這張圖來說明，HL1 依賴 <I> 介面，早期我們大多用 OO 中的多型來達到這個效果，就是 HL1 要呼叫 ...

以領域為中心的：線上房貸申請系統設計 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，而根據需求，需求中銀行顧客可以到線上房貸申請首頁，使用網銀帳號或初次申請進行簡訊驗證後方可填寫...