技術架構設計12原則（上篇）

在「架構能力的四個階段」一文中，我提到我把架構的能力分為四個階段，分別是架構原則（principles）、架構模式（patterns）、架構建模（modeling）、架構框架（frameworks）。其中第一個階段是「架構原則」。架構原則是在架構設計領域中基本要遵守的原則，通常不會有太多條，且每一條都很簡單、用處很廣泛、彼此獨立。我自己目前就建立了12條技術架構設計指導原則，這篇文章的目的就是為了跟iThome的讀者分享這些原則。

架構原則1：不要使用Stored Procedure，因為這會讓業務邏輯難以維護。資料庫管理系統（DBMS）裡面可以直接執行PL/SQL等程式，這種程式叫做Stored Procedure。這些年我在許多金融公司的工作經驗讓我發現Stored Procedure的問題重重，導致業務邏輯難以維護，應該盡量避免使用Stored Procedure。當然，不排除有人能把Stored Procedure的程式碼寫得非常好，有很好的抽象隔離和模組化，使得系統容易維護，但我看到的實際狀況都不是如此，且Stored Procedure讓業務邏輯和資料的儲存結構結合得太緊密，這在未來系統調整時也會一個巨大的風險。

有人認為Stored Procedure直接在資料庫內處理資料，執行效率比較好。但任何選擇都有機會成本和風險，Stored Procedure非常可能會帶來業務邏輯難以維護的危害，比起它帶來執行效率提升的利益，大多數的情況下我們會選擇「讓業務邏輯好維護」。效率當然重要，但在這個時代，執行效率的提升通常會透過彈性靈活的分散式系統來達成，而不是透過單一個龐大系統效率的垂直提升。

架構原則2：一個系統內部可以包含儲存和程式碼，但系統間不能共用資料庫。一個系統應該完整地控制自己的資料庫，所有對資料庫的存取都必須透過系統本身，不能直接去讀寫資料庫，不光是不允許其他系統「寫入」此資料庫，就連「讀出」資料也不行。如此以來，系統之間的依賴只透過API，當系統根據需要調整自己的資料格式和資料解讀方式時，其他系統並不會受到影響。

架構原則3：邏輯容易變動的程式碼必須剝離成另一個系統，容易變動者（例如應用系統）可以依賴較不容易變動者（例如平台系統）。提前做好這個剝離的動作，後續在業務功能變化時，好處就很明顯了：需要要修改和測試的部分就會最小化，範圍可控。

架構原則4：任何系統都不能依賴容易變動的系統。這一條原則和上一條原則是有關聯的。容易變動的系統可能API的規格不穩定，且內部功能的穩定性也比較低，依賴這樣的系統就會導致你的系統也很容易受到影響。

架構原則5：被調用方必須提供清晰、文件化的API。當我做系統設計評審時，我非常關心API設計的良窳。好的API可以讓使用者一目了然，且有說明清楚的文件。關於API的設計，我的經驗是「核心系統」的API要做到彈性至上，API的數量少，但每個API的參數個數比較多，這麼設計的好處是可以避免核心系統經常需要修改。比較靠近應用的系統要做到使用的方便性至上，API的數量多，但每個API的參數個數比較少（且盡量讓參數有預設值，可以空缺不設定）。

架構原則6：使用者界面要被剝離出來，且使用者界面內盡量不要有邏輯。使用者界面內可以有佈局（layout）和操作等和業務無關的程式邏輯，但只要和業務有關的邏輯，一定要剝離出來。這麼做的好處是，可以在不同的終端設備之間共用業務邏輯。

這篇文章先介紹六條架構原則，下一篇再介紹剩下的六條架構原則。