技術架構設計12原則 上篇, 下篇

架構原則7:調用外部廠商的系統時必須只依賴SPI(Service Provider Interface,服務提供者界面),不依賴具體的系統

架構原則8:業務邏輯的程式碼必須區分服務(service)和物件(object),服務沒有狀態,物件有狀態,服務操作物件,物件的狀態記錄在資料庫(和外部系統)

架構原則9:服務不能直接讀寫資料(和外部系統)

架構原則10:物件狀態的保存方式必須做出隔離,也就是提供資料隔離層

架構原則 11:充血模型才是好的物件模型。且設計模型時,要考慮是否有強一致性的要求

架構原則 12:禁止循環依賴

SPI是我們設計好介面標準,且其他廠商的系統要實現這個標準

當我們的SPI和廠商的API之間有差異,無法銜接上,這時候要靠Adapter

目的: 要做到我們的業務邏輯和廠商系統之間有隔離

避免外部系統的各種狀況(例如外部系統介面變更)

保留更換外部合作廠商

同時有多個同類型合作廠商的可能

例外: 如果我們的系統本身就是容易變動的系統

模型可以分為二種:資料模型、程式碼模型

服務單純是程式碼模型

物件主要是資料模型,搭配一部分與資料密切相關的程式碼模型

例外: 容易變動的簡單系統

資料(和外部系統)一定要通過物件的包裝與解釋,才能被服務操作

嚴守分層不跨層,有助於架構的簡化

物件不需要知道狀態是保存到資料庫或外部系統

和架構原則7描述的SPI使用同一個隔離層即可

架構原則1:不要使用Stored Procedure,因為這會讓業務邏輯難以維護

例外: SP 寫的好且管理規劃好

架構原則2:一個系統內部可以包含儲存和程式碼,但系統間不能共用資料庫。

架構原則3:邏輯容易變動的程式碼必須剝離成另一個系統,容易變動者(例如應用系統)可以依賴較不容易變動者(例如平台系統)

架構原則4:任何系統都不能依賴容易變動的系統

架構原則5:被調用方必須提供清晰、文件化的API

架構原則6:使用者界面要被剝離出來,且使用者界面內盡量不要有邏輯

一個系統應該"完整地"控制自己的資料庫

對資料庫的存取都必須透過系統本身,不能直接去讀寫資料庫

不允許其他系統「寫入」和「讀出」此資料庫

系統之間的依賴只透過API

「核心系統」的API要做到彈性至上,API的數量少,但每個API的參數個數比較多

避免核心系統經常需要修改

比較靠近應用的系統要做到使用的方便性至上,API的數量多,但每個API的參數個數比較少(且盡量讓參數有預設值,可以空缺不設定)

不同的終端設備之間共用業務邏輯

核心概念

會變動部分抽離變成獨立層

架構是一種思考方式