領域驅動設計簡介(1) - 貧血的領域模型

領域驅動設計簡介(1) - 貧血的領域模型

目前執行的專案使用 Spring MVC 開發，設計分層式的架構，主要將系統架構分為四個層次：

1. User Interface Layer (使用者介面層)：以HTML/JavaScript，搭配Spring MVC、JSON與後端溝通。
2. Web Layer (控制器層)：以Spring MVC Controller實現MVC架構。基本上Web Layer負責兩件事情，一為與前端互動，提供JSON API等，並將使用者導向目前對應的頁面，二則作為前端HTTP與後端Service溝通的橋樑。
3. Service Layer (服務層)：服務層包裝所有商業邏輯(business logic)，將控制器層需要執行的任何「動作」包裝成一個個的「服務」。Web Layer呼叫時不會接觸到任何的商業邏輯，由Service Layer來控制所有商業邏輯，並於需要的時機傳遞至下方的 Persistence Layer。
4. Persistence Layer (持久層)：持久層負責處理領域物件的儲存(Persistence)，提供DAO讓服務層呼叫，將物件儲存在實體儲存設備上(如資料庫、檔案)。
5. Domain Model (領域模型)：經過物件導向分析設計後的領域模型，作為各層次間溝通的主要統一結構。基本上這邊的領域模型只會包含屬性以及對應的getter/setter，不會有任何的商業邏輯。而在需要報表查詢等特殊的情況下，會另外建立查詢用的模型，類似Martin Fowler的CQRS模型。

上述這個架構的好處是，各領域間的職責分離的相當清楚，以共通的Domain Model貫穿整體架構，各架構之間有一定的模型作為溝通的橋樑。所有的商業邏輯皆被包含在Service Layer之中，任何一層皆可以輕易的做抽換。
然而在開發的過程中，發現所有的商業邏輯皆被集包含在 Service Layer，所有的 Domain Model 被設計的再漂亮，卻因為不包含任何商業邏輯，只是單純的作為資料傳遞用，英雄無用武之地。平時所學的那些物件導向設計原則、設計模式，也沒有過多可以派得上用場的地方。
因此，跑去找了一些相關的，發現Martin Fowler也曾經提出過一個模式 Anemic Domain Model，中文可翻為貧血的領域模型。在這篇文章中，Martin Fowler 淺顯直白的說出這樣的一個模式與物件導向是相馳的，而且因為Domain Model與底層資料庫進行O/R Mapping，但卻又沒有善用它的好處，反而導致開發的成本提高。
今天先提到這邊，下一次將會開始介紹「領域驅動設計(Domain-Driven Design)」。