「技術架構設計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技術,而是一種思考方式。

作者簡介


Advertisement

更多 iThome相關內容