l

2018年7月4日 星期三

Clean Architecture(4):架構三原則首部曲—分層原則

July 3 14:38~15:58

螢幕截圖 2018-07-03 16.08.32


前言

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

***

階層式架構

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


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

螢幕截圖 2018-07-03 14.55.57


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

一般直覺的看法: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中的六角型。

螢幕截圖 2018-03-15 17.39.22


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

CleanArchitecture


▲上圖中,蛋黃區(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。

沒有留言:

張貼留言