小朱® 的技術隨手寫

之前其實就有想寫這一篇，但是因為很忙而擱著，今天看到了某些網路文章，才讓我起意把這篇補起來。早期我寫了一系列關於架構師先決條件的文章 "邁向架構師的暖身運動"，簡單說明了怎麼由架構的角度去思考系統設計的方略，今天就用這篇文章將它做個總結吧 (謎之音：其實是你自己懶吧)。

切面導向設計是一個很有趣的技術與設計架構，它可以允許開發人員在程式執行時期在方法 (method) 中植入共用的一些操作，而且不需要由開發人員自己加，直接在核心系統中註冊就能得到植入操作的功能，最常見的例子就是記錄 (logging)...

一般來說，設計與規劃一個軟體系統，不外乎是符合需求，具有前瞻性，創新力，或是試水溫等等，不管是哪一種，只要是一個有經驗 (或是現在就在做) 的系統設計師 (系統分析師亦然) 都會想要把軟體系統設計得具有十足的彈性，並且具有無限的擴充性，

邁向架構師的暖身運動 (8)：不要小看 PoC 的重要性

邁向架構師的暖身運動(7)：愈了解基礎知識，愈具有架構設計的能力

記錄(logging)這件事在中大型應用系統中，是非常重要的一環，它可以重現資料變動的前後狀況，以及是誰去動了資料，如何動資料等等，除了作為財務部門稽核的基本資料外，也是一種保護自己的證據。

適才點部落正在舉行 ASP.NET 的修練大會，雖然我這篇文章與 ASP.NET 修練大會本身沒啥關係，但我認為卻是很多想做分層應用程式(Multi-tier Application)或是迷惘在為什麼應用程式總是要重寫很多次的開發人員應該要知道的概念。

如果可以由資料庫本身去做彈性設計的話，對於物件使用 ORM 以及擴充上會有正面幫助，物件可以不受物件既有資料表欄位的限制，即可由物件自己去決定會多或會少哪些資料，而資料庫依照物件的要求做出反應，即可確保物件的高彈性，又可以簡化資料表的設計。這個方法即為 Profile 架構。

適當的設計，應該是考量各種可能情況，對程式做的具彈性且可重覆使用的軟體設計，除了基本的物件導向規範以外，還要加入一個守門員的角色：規則（Rule）以及驗證器（Validator）。

只要程式開發久了，又有面對過不同層次的專案（例如產業不同，性質不同，應用方向不同或是不同的領域知識等），通常都會接觸或是使用很多的技術，而且技術的學習力又和自己本身的基礎能力有相當大的關係，它會左右你學習新技術的快慢，不過今天要談的倒不是學習力，而是決策力（Decision Making）。

前幾天我在幫我顧問公司的員工上課，剛好講題就是 Software Architecture，我在課堂上順便問了一個小問題：Framework 和 Architecture 有什麼不同？結果學員多數都答不出來，因為那間公司都把 Framework 叫做架構，但光是架構這個詞在很多技術用語上都會被套到，那麼，Framework 和 Architecture 到底哪裡不同？

一般在寫程式的時候，往往都是要先探詢寫這支程式的需求是什麼，如果有些工作是由流程 (process) 構成的，或者是這件工作可能會橫跨不同的模組（或資料庫），又或者是這個程式預期未來可能會有什麼樣的衍生功能時，就可以試著把這些程式中共同的部份加以抽出，獨立構成一個公用程式庫 (utility) 或是基礎類別 (base class)，而將這些部份抽出的流程即稱為抽象化 (abstraction)。

介面導向設計(interface-oriented design) 在軟體架構設計中，是一個必修的技能，不過在整個軟體架構領域中，它只是個入門磚而已，沒有它，想要做好軟體架構是很困難的，原因只有一個：它是基礎。