架構原則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的參數個數比較少（且盡量讓參數有預設值，可以空缺不設定）
不同的終端設備之間共用業務邏輯
核心概念
會變動部分抽離變成獨立層
架構是一種思考方式