「架構能力的四個階段」一文中,我提到我把架構的能力分為四個階段,分別是架構原則(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)和操作等和業務無關的程式邏輯,但只要和業務有關的邏輯,一定要剝離出來。這麼做的好處是,可以在不同的終端設備之間共用業務邏輯。

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

專欄作者

熱門新聞

Advertisement