Clean Architecture（4）：架構三原則首部曲—分層原則

July 3 14:38~15:58

前言

《Clean Architecture》這本書一共有34章，全部讀完也是有點累。今天Teddy幫鄉民們整理一下重點，總地來講Teddy認為Clean Architecture有三個最重要的原則，將分三集逐一介紹這三個原則。今天先談「分層原則」。

***

階層式架構

軟體架構就是軟體的形狀（shape），而形狀是由多個元件及其互動所構成。這些元件通常會依據其功能加以分類，以便於管理、擴充與維護。

▼階層式架構就是一種很常見的分類方法，常見的階層式架構長成下面這樣 （詳細說明可參考https://goo.gl/Tjq75M）：

既然稱為階層式架構，一定有上、下層之分。請問上圖階層式架構中，誰是上層、誰是下層？

一般直覺的看法：Presentation Layer畫在架構的最上方，所以它是最上層，而Database Layer在最下方，所以它是最下層。這種解讀有一個問題，因為在階層式架構中，越上層的人（元件）通常擁有越核心的商業邏輯（business logic）。如果Presentation Layer是最上層，那豈不是代表它擁有最核心的商業邏輯？這也不對啊，因為大家都知道，儘量不要在Presentation Layer放置商業邏輯，因為那將使系統擴充、維護與測試變得更加困難。

***

定義高層與低層

《Clean Architecture》書中關於分層有一個非常明確的定義：「離I/O（輸入、輸出）越遠的元件層級越高，離I/O越近的層級越低」。這其實也很容易理解，在公司中，櫃台小姐離I/O（接電話、接待訪客）最近，通常層級比較低。董事長、總經理離I/O很遠，層級最高（通常看高階主管的辦公室位置離大門遠近就可猜出層級高低XD）。

▼Port and Adapter不把階層式架構畫成常見的垂直形狀，而是畫成圖1中的六角型。

▼《Clean Architecture》書中則是畫成同心圓（圖片來源在此）。

▲上圖中，蛋黃區（Entities）是架構中層級最高的一層，而最外圈屬於I/O層，是層級最低的。

《Clean Architecture》書中有四個預設的階層，分別是：

• Entities：也就是傳統物件導向分析與設計所說的domain model object。
• Use Cases：Entities這一層存放著核心商業邏輯，也就是在這個領域中，不同應用程式都用得到的物件。而Use Cases則代表應用程式邏輯，也就是應用程式的功能。Use Cases扮演著controller的角色，呼叫Entities或是Repository物件提供應用程式對外的服務。
• Interface Adapters：將外部資料與呼叫介面透過此層轉呼叫Use Cases，如此一來Use Cases就可以與I/O或是應用程式框架無關。
• Frameworks and Drivers：此層包含了應用程式框架，例如如果Java程式使用了Spring Framework，則Spring Framework就位於這一層。資料庫，或常見的MVC Framework也都位於這一層。通常大家在這一層所寫的程式都只是為了把應用程式框架與內部的Interface Adapters或Use Cases串起來的膠水程式，鮮少有複雜的商業邏輯會位於這一層。

***

結論

依據「元件距離I/O遠近」分好層級之後，高、低層之間的界線就非常的清楚。層級分明之後，接下來衍生出另一個問題：每一層之間的相依性要怎麼管理？如果層與層之間的相依性沒有好好管理，僅僅是分層你的架構還是很可能會一團亂。

下一集「相依性原則」將說明這個問題，下次見。

***

友藏內心獨白：真正的高層都是坐在離I/O很近的大門口XD。