Entity Framework 領域驅動設計實踐（二）：分層架構深度解析

在進入具體實例之前，我們有必要回顧並深入理解分層架構。「層」是一種架構模式，也是軟體從業者最廣泛、最靈活運用的模式之一。雖然許多開發者知道「三層架構」即表現層、業務邏輯層與資料存取層，但真正理解如何正確分層、各層職責邊界在哪裡，卻非易事。

領域驅動設計（DDD）同樣建立在分層模式基礎上，但它更強調領域架構與技術架構的分離，這是與傳統分層架構的本質區別。

傳統三層架構的局限

最常見的分層方式是「表現層、業務邏輯層、資料存取層」，架構示意如下：

圖中虛線框出的「基礎設施層」在實踐中常包含 SQLHelper、TextUtility 等工具類，可被各層呼叫。依分層原則，表現層僅與業務邏輯層交互，業務邏輯層透過資料存取層進行持久化操作，表現層對資料存取層一無所知。

從 DDD 視角看，這種分層存在明顯弊端：

• 基礎設施層職責混亂：既可能是純技術框架，也可能包含業務邏輯，導致業務邏輯層對其產生依賴。
• 過度強調「資料存取」地位：將「資料存取」與「業務邏輯」置於同等重要位置，誘導開發者以資料庫設計為起點（如「我的資料表該怎麼設計？」），而非領域建模。

領域驅動設計的四層架構

DDD 將系統劃分為四層：基礎設施層、領域層、應用層、表現層。資料存取層不再獨立，而是下沉至基礎設施層。

各層職責詳解

• 基礎設施層：為其他各層提供技術框架支撐，不包含任何業務知識。資料讀寫屬於技術範疇，故資料存取歸於此層。
• 領域層：核心層，包含實體、值對象、領域服務及其關係，具體表現為領域模型。DDD 提倡富領域模型，盡量將業務邏輯封裝在領域對象內，無法歸屬者以領域服務形式定義。
• 應用層：不包含領域邏輯，負責任務協調與應用狀態維護，側重流程編排。有時稱為「工作流層」。此層在 DDD 實踐中爭議較大，職責邊界常模糊，後續章節將專門探討。
• 表現層：與傳統三層架構類似，但注意 Web Service 屬於表現層 而非服務層。

層間通訊：DTO 的關鍵作用

表現層與應用層透過資料傳輸對象（DTO）交互。DTO 是無行為的 POCO 對象，僅用於封裝領域對象數據、實現層間數據傳遞。不可直接使用領域對象傳輸，原因有二：

1. 領域對象關注領域語義與行為，DTO 關注數據結構，職責不同。
2. 富領域模型包含行為，若直接暴露給表現層，將破壞封裝、導致邏輯洩漏。

下一章將以簡單的銷售系統為例，示範 Entity Framework 下領域驅動設計的具體應用。