小朱® 的技術隨手寫

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

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

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

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

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

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

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

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

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