雖然技術層面 DataTable 與 EntityObject 不可直接比較，但這隱喻著一場靜悄悄的革命正在發生——即便是微軟，也無法置身事外。軟體設計思想亟需革命，必須擺脫以資料庫為中心的傳統思維，轉向面向領域的道路。
當前軟體開發現狀令人憂慮：大量從業者仍將焦點鎖定在資料庫設計上，頻繁詢問「我要實現某功能，資料表該怎麼建？」這犯了根本性錯誤——軟體的目的是用計算機解決現實領域問題，而非研究資料如何更合理地存儲。這一觀點我在早期博文中反覆強調。
.NET 4.0 帶來了 Entity Framework（EF），不僅提供技術框架，更交付了一套面向領域的解決方案。本系列將結合 DDD 實踐知識，剖析 EF 的具體應用過程。雖然當前 EF 尚不完善，但期待微軟持續演進，使其成為微軟領域驅動工具箱的核心角色。
領域模型 ≠ 資料模型。領域模型表達領域中類及其關係（組合、聚合、繼承、實現、約束等），而資料模型僅有一對多、多對多。從 DDD 視角，資料庫只是存儲實體的外部機制，屬技術層面。資料模型描述領域模型的持久化方式，必須先有領域模型，再有資料模型，透過映射產生對應資料模型。因此框架必須支撐領域模型到資料模型的映射。
EF 支援從領域模型生成資料庫 DDL，也支援從資料庫結構生成「領域模型」。我認為後者應移除，因為純資料無法描述領域概念。例如資料表命名為 "abc" 仍存客戶資料，EF 會生成名為 "abc" 的類，這能算領域對象嗎？資料依賴於實體，是實體的狀態，脫離實體的數據毫無意義。
圖中標記內容依 DDD 思想不應持久化，但 EF 為兼容性保留了此功能。
聚合是表達同一概念的相關實體集合（如銷售訂單、訂單行、商品），訂單為聚合根。引入聚合是 DDD 處理大型系統的獨到方式：實體眾多、關係複雜時，從持久化機制「喚醒」實體無需載入所有關聯對象，只需關注當前問題域。例如讀取客戶資料時，可能顯示其所有訂單，但不會一次性載入所有訂單行。
EF 目前不支援聚合概念，所有實體被平鋪在 ObjectContext 的 EntitySet 中。後續文章將介紹如何在 EF 中引入聚合。
領域模型對象分實體、值對象、服務。LINQ to SQL 不支援值對象，EF 以 ComplexType 支援。兩點補充：
對象天然應有行為，以自然方式描述現實領域。遺憾的是，EF 的 Entity Data Model Designer 僅支援屬性圖形化定義，不支援行為定義，導致無法定義方法重載/覆寫——這恰是業務邏輯核心。期待下一代 EF 能推出 "Entity Model Designer"。目前可透過 C# partial class 向實體注入行為，不影響領域描述性。
EF 支援從資料庫存儲過程生成實體方法，從根本上混淆技術問題與領域問題。存儲過程面向資料，實體方法面向領域，建議移除此功能。後續文章將深入探討。
接下來的系列文章，我將逐步探討如何在 EF 上應用 DDD 思想，完成案例程式開發。
