隱私權聲明
本公司關心使用者隱私權與個人資訊,並遵守本公司的網站隱私政策,使用者若有任何問題,可以參考本公司的「網站隱私政策」,或利用電子郵件或連絡電話詢問本公司.
2020
01
14

[轉載] 技術架構設計12原則(上篇)

關鍵字:程式設計專案開發

架構原則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)和操作等和業務無關的程式邏輯,但只要和業務有關的邏輯,一定要剝離出來。這麼做的好處是,可以在不同的終端設備之間共用業務邏輯。

你可能有興趣的作品案例
傑立資訊傑立資訊事業有限公司
Powered by AWS Cloud Computing

電話:(02)2739-9096 | 傳真:(02)2739-6637 | 客服:[email protected] | 臺北市信義區和平東路3段257號6樓map

© 2019 傑立資訊 All rights reserved.| 網站隱私政策

線上詢價