發表文章

軟體架構設計:無題

圖片
軟體架構設計:無題 Logo 圖片、六角架構 取自:https://reflectoring.io/spring-hexagonal/ 前言 為什麼叫做無題?因為軟體架構設計是一個相當龐大的主題,也不可能在一篇文章中談完,先前我也曾寫過許多架構設計系列文、包括領域驅動設計 DDD 與 整潔架構 Clean Architecture 與如何在以上的軟體架構為基礎來落實 TDD。 今天,我在以更廣泛與更實務的角度來探討軟體的架構設計,文之中也會搭上我這些年來所設計的框架、Framework 並對上也是這些年後來所讀的相關書籍、像是 DDD 領域驅動設計、Uncle Bob 的 整潔架構 Clean Architecture、還有正在讀的【Get You 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 雲端運算的環境中。 原歸正傳,所謂

關於 Visual Studio 支援 IWizard 的範本套件開發

圖片
關於支援 IWizard 的範本套件開發 關於 Visual Studio 範本 以下提及的 Project Templates = 範本 小弟蠻多文章、線上課程、或者在社團分享許多關於 Visual Studio 範本開發的相關資源,也成立裡書社團【台灣 Visual Studio Extensions 套件開發俱樂部】。 事實上、Visual Studio 如果是單純的 範本開發 也就是 C# Project Templates 最簡單的方式就是(匯入/匯出)範本,但是這完全沒什麼彈性 與 擴充性可言,更不用說你想做出像互動式精靈甚至 Generate Code產生專案程式碼骨架等等,這就不是單存範本能夠做到,這就得透過 VS IDE/envdte/IWizardTemplates 才能夠做到,也就是得使用一些 Visual Studio IDE 的一部分功能才能夠做到。 為 Project Templates 加入 Code Generate 的功能 在我最早期的 MyORM 裡即提供一種動態入 Entities/DbContext 的功能、甚至我能 Generate 自己框架的 Source Code 進來。 IWizard 很多人都知道 IWizard,這裡就不多談,它只是進入互動 Project Templates 的一張門票而已,它讓你的 Templates 跟 IDE 建立互動的機制 + 取用 IDE 的功能,它的功能也不只如此,不過若您不清楚如何建立支援 IWizard 的 Project Templates 可以參考我的線上課程: 團隊開發系列-設計符合團隊的範本精靈 (Project Template) 課程連結: https://hiskio.com/courses/192/about?hi=MNJ7EJRV3Z4L&s=tc 。 .NET 6 中的範本開發 由於 .csproj 專案格式的改變間接影響到 Project Templates 的開發,怎麼說呢?因為 Project Templates 為 Visual Studio 擴充性的一部份,這其實從 VS2010 開始,Logo 圖其實就有說明這一點了。 安裝了 Visual Studio 擴充功能後,你可以找到『延伸模組』 且會有【VSIX Pro

從整潔架構談自定義 NuGet 套件規劃與使用

圖片
從整潔架構談自定義 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

軟體工程師 - 成長的 10 個階段

圖片
軟體工程師 - 成長的 10 個階段 前言 先前,我在 Study4 小聚 #6 分享的一場關於軟體工程師 & 架構設計的養成之路,在該議程中,我分享了軟體工程師的 10 個階段(你的階段如有雷同、應該是...純屬巧合。XDDD) 哪 10 個階段? 我將軟體工程師的成長依序分為 10 個成長階段,因為隨著技能的提升,你該擴充的 不會只是只有軟體開發技術,溝通與協作能力尤其重要 ,也像是『康威定律』中所提到的, 你的軟件的設計 & 或系統設計本質上反映了企業的組織機構。系統各個模塊間的介面的設計,也反映了企業各個部門之間的信息流動和合作方式,些技能再進行軟體架構設計時也息息相關 ,團隊在進行模組設計時需要頻繁的溝通,這些、都是是否能將軟體做好的關鍵因素。 如 Logo 圖片,我依序說明每個階段的成長歷程。 1). 初始開發階段、熟悉 Programming/Developer 階段(PM/PO 給規格後加以實作出來) 2). 此階段代表已懂得透過重構來讓程式碼有基本的可維護性、已能熟用 DRY (Don't Repeat Yourself) 3). 這裡的專案收尾代表對於專案開發已經有某些程度的認知、掌握度。我所提的掌握度在於了解『技術債』的產生緣由 與 危害,在 Programming/Devloper 層面懂得透過 SOLID/Design Patterns 解決問題 並 自我成長。 4). 我這裡用『紀錄』 代表能運用所學 + 將使用者需求運用 〔邏輯思考〕 與 〔抽象化〕 轉化為程式碼 + 並能自我成長將經驗保存下來。我認為這是跨越只是(寫程式/實作)進入另一個門檻的重要經驗與歷練。 5). 此階段含括上面所有技能,並能夠與〔團隊〕和〔客戶〕協作、並產生出〔產品〕。 6). 結合以上、此階段已知流程與規範嚴重影響團隊的協作,這裡還能洞悉流程改造 + 傳承流程與經驗。 7). 同樣結合上述條件, 這裡還能〔跨團隊〕或〔跨公司〕進行流程的改造與升級 。因為已經洞悉軟體開發生命週期的大小事情、熟悉每一個階段會產生的 問題 與 如何修正 與 改造 。 8 ). 我這裡的獨立作業不是工作上的獨立作業,而是代表可獨立的對團隊或公司的流程或規範進行指導、清楚缺失 與 問題發生的原因 + 如何改善等。 9). 為什麼我

學習 Event Storming 事件風暴的感想

圖片
學習 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 領域驅動設計文章導讀

圖片
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 更加分) 為什麼第三點我要特別提到『若有接觸過分析階段的 UML 更加分』呢? (1)分析階段的 UML 是什麼?(2)以及為什麼一定要使用 UML? 我先回答第二個問題,UML 只是眾多分析階段圖形的一種,像是 BPMN, SysML 也都是業界的商業分析中,常見的圖形分析 Syntax/Notations 等表示法,但我的重點是在於說,分析階段進行的是[正向工程]的開發, 可能許多朋友

#讀書趣(1):Patterns of Enterprise Application Architecture

圖片
  今天重看這本電子書:【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 and solution space (問題空間 與 解決方案空間)

圖片
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 如何處裡狀態?(三) 前言 先前分享過幾篇關於 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 ),為什麼說部份呢?因為這裡目前無任何商業邏輯 (Domain Layer) 與 (app service/u