PoEEA之Server Layer

September 07 22:36~23:20

▲PoEAA書中提到四種表達領域邏輯的模式

緣起

好一陣子沒幫部落格文章增加新分類，今天這一篇開啟【盡信書不如無書】這個分類，紀錄Teddy讀書時看到一些自己覺得怪怪的地方。

***

哪裡怪
前幾天Teddy在準備Asian PLoP 2020的演講題目：〈Pattern-Based Problem Solving: One Pattern at a Time〉，翻到《Patterns of Enterprise Application Architecture》第九章Domain Logic Patterns，看到Service Layer這個模式，如圖1所示。

▲Service Layer模式，節錄自《Patterns of Enterprise Application Architecture (PoEAA)》，133頁。

這本書2003年出版至今已有17年，當年Teddy讀到這個模式、看到這張圖，並沒有什麼感覺。但因為這幾年學了Clean Architecture，前幾天再次看到這張圖，當下就覺得不對勁：「Data Source Layer怎麼會畫在軟體架構的最核心？」。

***

資料庫是細節

Clean Architecture四層架構如圖2，資料庫屬於最外層，並非如PoEAA所畫的位於最核心。軟體架構的核心應該是Entity Layer，也就是Domain Model Layer。

▲圖2：《Clean Architecture》建議的四層架構，畫成同心圓（圖片來源在此）

在階層式架構中，把資料庫畫成底層或是核心層，在N年前也算是常見的畫法。但以現在的角度來看，對照圖1與圖2，應該可以很清楚看出來，圖2的觀點比較正確。資料庫、使用者介面、框架、驅動程式等，都屬於細節，屬於階層式架構的外層，並非是核心部分。

其次，傳統階層式架構所說的Service Layer，就是Clean Architecture裡面的Use Case Layer。Teddy現在覺得Use Case Layer比較具體，因為Service這個字有很多種含意，因此用Service Layer來代表應用程式所提供功能或服務的邊界，好像有點那麼不是很直覺（就跟這句話一樣XD）。

***

讀書不是照單全收

PoEAA是一本很棒的書，書中所整理的模式很多到今日依然適用且日久彌新。但也有一些模式的內容，因為時代演進需要稍微修正，像今天介紹的Service Layer就是一個例子。

讀書不是照單全收，有時候同意，有時候疑惑，有時候反對。理論上，除非這本書有問題，否則同意的時候應該居多。疑惑時可能是自己離作者太遠，尚無法理解書中的微言大義，但也能不排除內容有誤的能性。

反對，代表自己有看法，這個看法與書中不同。自己的看法可能是錯的，也可能是對的。能夠說出不同，也算是一種讀書的層次。

***

友藏內心獨白：挑毛病也要講出個道理。