技術架構設計12原則（下篇）

在「技術架構設計12原則（上篇）」一文中，我提到我目前的架構原則有12條，且該文還介紹了其中的六條。這篇文章接續介紹剩下的六條。

架構原則7：調用外部廠商的系統時必須只依賴SPI（Service Provider Interface，服務提供者界面），不依賴具體的系統。我所謂的SPI，和API的差異不大，主要是主客的視角差異。簡單來說，API是我們設計好介面標準，且我們實現這個標準，其他系統依賴這個標準；而SPI是我們設計好介面標準，且其他廠商的系統要實現這個標準，我們依賴這個標準。當我們的SPI和廠商的API之間有差異，無法銜接上，這時候要靠Adapter。

架構原則7的目的是，要做到我們的業務邏輯和廠商系統之間有隔離，避免外部系統的各種狀況（例如外部系統介面變更），並且保留更換外部合作廠商或同時有多個同類型合作廠商的可能。如果我們的系統本身就是容易變動的系統，那麼就不需要遵守這個原則，因為這麼做的工作量變多，但好處並不明顯。

架構原則8：業務邏輯的程式碼必須區分服務（service）和物件（object），服務沒有狀態，物件有狀態，服務操作物件，物件的狀態記錄在資料庫（和外部系統）。但容易變動的簡單系統，不需要區分服務和物件，因為這麼做工作量變多，但好處不明顯。在「架構的意義」一文中提到，根據使用方式，模型可以分為二種：資料模型、程式碼模型。服務單純是程式碼模型，但物件主要是資料模型，搭配一部分與資料密切相關的程式碼模型。

架構原則9：服務不能直接讀寫資料（和外部系統）。資料（和外部系統）一定要通過物件的包裝與解釋，才能被服務操作。嚴守分層不跨層，有助於架構的簡化。

架構原則10：物件狀態的保存方式必須做出隔離，也就是提供資料隔離層。物件不需要知道狀態是保存到資料庫或外部系統，所以這裡和架構原則7描述的SPI使用同一個隔離層即可。

架構原則 11：充血模型才是好的物件模型。且設計模型時，要考慮是否有強一致性的要求。充血模型有許多業務邏輯，讓介面可以直接被調用，可以減少許多服務多此一舉的包裝。

架構原則 12：禁止循環依賴。只要有循環依賴的存在，幾乎就預示著病灶，不是不發作，只是時候未到。就如同我在「大規模系統重構」一文中描述的那樣，破除循環依賴是重構的要點。

上一篇和這一篇文章一共描述了我的12條架構原則。這12條架構原則有個神奇的地方：我把他們一起用上，設計出我第一版的架構參考模型，也就是我在「架構能力的四個階段」一文中所提到的第三個階段。

事實上，這個過程是反著來的。幾年前，我對於經典的三層（3-tier）和四層（4-tier）架構不滿意，覺得太粗糙，我想要更細化的模型，於是我自己開始推演，從一大坨的系統開始推演，開始切割，我把每次切割的理由都想清楚，並記錄下來，就成了這12條原則。我曾經在我當時任職的金融機構內部開始培訓課程，把這個推演過程講出來，大家聽了覺得神奇。所以到底是這十二條架構原則衍生出我的架構模型，或者是我的架構模型抽取出這十二條架構原則，這已經說不清楚了。就像雞生蛋，蛋生雞。

而我的第一版架構模型又繼續演化，從一維、後來變成二維，三維（請閱讀「方法論設計的四個步驟」一文的描述），還演化出一個通用的編程框架（請閱讀「技術應用的艱辛探索」一文的描述）。在探索這一切的過程中，我發現知識是如此的曼妙。架構對我來說，已經不再是一種IT技術，而是一種思考方式。