Gelis 技術隨筆-部落格

雜談：軟體設計中 Cross-Cutting Concerns 的重要性 圖（一）、Cross-Cutting Concerns 跨領域關注點 前言 什麼是 Cross-Cutting Concerns 跨領域關注點？我比較少專注談論這個主題，事實上，這不是什麼很新的技巧，也不是什麼狠了不起的高端技術，只不過，我認為有些設計技巧是這樣，看似不難，不過要真的能在專案、實務上的軟體架構中均衡的實踐，那就有一定的難度。 實踐部分，常見的手法即是 AOP, Aspect Oriented Programming 後面都簡稱 AOP，而這個技巧在 .NET C# 上就有多種實踐手法，這個早在 2014 年時，我替竹科某廠所設計的 Web API Framework (net451) 的框架裡，就充分利用這個技巧來將系統服務，像是 Logger (紀錄)、Exception Handlers (例外處裡機制)、Notification/SMS (通知) 等等的實作 與 商業邏輯分開。實作方法我們稍後來說明。 什麼是 Cross-Cutting Concerns 跨領域關注點 這其實是軟體開發上，一直存在的普遍問題，這問題在傳統階層式架構上也存在，我發現訪間有些文章扯進了 Clean Architecture 整潔架構，事實上不管你使用哪一種架構， 這類跨越不同層的程式碼卻還是得因為某些 None-function 的需求，得相依某些底層服務的問題，其實一直存在 。 通常在設計系統時，關注點分離，讓我在實際進行開發時，只需要專注在某一個模組/Layers 而不需分散注意力在其他的模組或者不同層次的位置上，且開發完成，不需考量各層彼此如何介接，因為每一層早已經定義好彼此互通所使用的協定與溝通的方法，像是 MVC 即是類似的框架。 回到跨領域關注，在軟體的開發上，尤其在企業商業邏輯的開發上面，在程式碼的實作上，我們知道程式碼當然是越簡單、行數越少越好，再說 SRP 也告訴我們一個元件、一個 Method 最好只有一種被修改的理由越好維護，只不過實際的程式碼。為了寫 Logger，為了實作驗證等，往往一定會與底層相關套件或模組相依，總還是會有部分程式碼讓這一個被修改的理由中，相依著其他外部組件、套件，這些在 Clean Architecture 裡，應該屬於 Infr

軟體架構設計原則：導論 我說明一下，為什麼會有這篇文章？因為最近，我正在籌備一個全新的課程，這門課算是我多年來在企業端顧問 + 也包括帶團隊做專案，也包含了幾次替企業客製化 API Framework 框架的相關實作經驗的體現。 記得，好幾年前我分享過一堂關於【 您的軟體架構構敏捷嗎？ 】的課程，這堂課程其實就是在告訴你，實務上進行開發時，沒有什麼開發的需求得要完全的想清楚、完全得清楚該怎麼做 + 或者是得完全的分析清楚後，才能進行程式碼的開發與撰寫。在敏捷的環境裡面，你沒有一項任務是進行所謂的軟體架構設計，但是你卻還是得進行當下適當的架構設計，這其實還蠻抽象的，但是你不應該在這個抽象預想、或者設計太多未來不太會用到、或者是根本不會用到的抽象設計在裡面，因為太多的設計一部分也又回到瀑布式的時代，難道你得全部分析完，才能開始寫程式？ 但.. 最近我也有篇文章【 為什麼我說在撰寫程式之前，還是先做個簡單的分析比較好？ 】說明，撰寫程式之前，還是先做個簡單的分析比較好？所以，那到底，我一開始要分析，還是不分析呢？答案是：你要做基本的抽象分析，但是只是做應該做的部分，什麼是目前應該做的部分？這其實需要蠻多相關的經驗，也沒有實際的標準答案，方早在與蔡煥麟老師互動時【FB 連結： https://www.facebook.com/share/p/PdntjirACrAvVhmw/ 】，我腦袋也迸出許多這些年來的設計與經驗感想出來 XD 圖（一）、DDD 戰術建模 - 建置 API 服務 通常，我們在進行系統開發時，會進行部分抽象的設計，在敏捷裡，我們可能會以價值為最優先考量來進行設計，但這個設計裡面，我非常喜歡 DDD 的 Core Domain 的概念，我不講過多的技術、也不希望有過多的平台設計或者框架的影子在裡面，我只希望先 Focus 在這個領域 (Domain) 裡面就好，因此，在藉由 Clean Architecture 的 Plug-In 的架構裡，我就可以先避免掉其他無用的抽象設計，也因此可以幾乎避免掉爾後的疊床架屋的設計出現。 圖（二）、先前小弟一堂課【利用物件導向五大設計原則 S.O.L.I.D. 來建立強固的軟體系統】的部分截圖 在不久前，約今年初，我也在企業授一堂課，關於透過 SOLID 建構六角架構的課程，這一堂課的主要內容其實也不是在