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