Please enable JavaScript.
Coggle requires JavaScript to display documents.
技術架構設計12原則 上篇, 下篇 (架構原則7:調用外部廠商的系統時必須只依賴SPI(Service Provider…
技術架構設計12原則
上篇
,
下篇
架構原則7:調用外部廠商的系統時必須只依賴SPI(Service Provider Interface,服務提供者界面),不依賴具體的系統
SPI是我們設計好介面標準,且其他廠商的系統要實現這個標準
當我們的SPI和廠商的API之間有差異,無法銜接上,這時候要靠Adapter
目的: 要做到我們的業務邏輯和廠商系統之間有隔離
避免外部系統的各種狀況(例如外部系統介面變更)
保留更換外部合作廠商
同時有多個同類型合作廠商的可能
例外: 如果我們的系統本身就是容易變動的系統
架構原則8:業務邏輯的程式碼必須區分服務(service)和物件(object),服務沒有狀態,物件有狀態,服務操作物件,物件的狀態記錄在資料庫(和外部系統)
模型可以分為二種:資料模型、程式碼模型
服務單純是程式碼模型
物件主要是資料模型,搭配一部分與資料密切相關的程式碼模型
例外: 容易變動的簡單系統
架構原則9:服務不能直接讀寫資料(和外部系統)
資料(和外部系統)一定要通過物件的包裝與解釋,才能被服務操作
嚴守分層不跨層,有助於架構的簡化
架構原則10:物件狀態的保存方式必須做出隔離,也就是提供資料隔離層
物件不需要知道狀態是保存到資料庫或外部系統
和架構原則7描述的SPI使用同一個隔離層即可
架構原則 11:充血模型才是好的物件模型。且設計模型時,要考慮是否有強一致性的要求
架構原則 12:禁止循環依賴
架構原則1:不要使用Stored Procedure,因為這會讓業務邏輯難以維護
例外: SP 寫的好且管理規劃好
架構原則2:一個系統內部可以包含儲存和程式碼,但系統間不能共用資料庫。
一個系統應該"完整地"控制自己的資料庫
對資料庫的存取都必須透過系統本身,不能直接去讀寫資料庫
不允許其他系統「寫入」和「讀出」此資料庫
系統之間的依賴只透過API
架構原則3:邏輯容易變動的程式碼必須剝離成另一個系統,容易變動者(例如應用系統)可以依賴較不容易變動者(例如平台系統)
架構原則4:任何系統都不能依賴容易變動的系統
架構原則5:被調用方必須提供清晰、文件化的API
「核心系統」的API要做到彈性至上,API的數量少,但每個API的參數個數比較多
避免核心系統經常需要修改
比較靠近應用的系統要做到使用的方便性至上,API的數量多,但每個API的參數個數比較少(且盡量讓參數有預設值,可以空缺不設定)
架構原則6:使用者界面要被剝離出來,且使用者界面內盡量不要有邏輯
不同的終端設備之間共用業務邏輯
核心概念
會變動部分抽離變成獨立層
架構是一種思考方式