DDD：談?wù)剶祿Ｐ?、領(lǐng)域模型、視圖模型和命令模型

DDD：談?wù)剶祿Ｐ?、領(lǐng)域模型、視圖模型和命令模型

背景

一個(gè)類(lèi)型可以充當多個(gè)角色，這個(gè)角色可以是顯式的（實(shí)現了某個(gè)接口或基類(lèi)），也可以是隱式的（承擔的具體職責和上下文決定），本文就討論四個(gè)角色：數據模型、領(lǐng)域模型、視圖模型和命令模型。

數據模型：面向持久化，數據的載體。

領(lǐng)域模型：面向業(yè)務(wù)，行為的載體。

視圖模型：面向UI（向外），數據的載體。

命令模型：面向UI（向內），數據的載體。

這是四種角色，可以由一至四個(gè)類(lèi)型來(lái)承擔，具體選擇幾個(gè)類(lèi)型需要考慮項目的上下文，但不同的選擇對編程的要求是不同的，下面舉幾個(gè)例子。

數據模型和領(lǐng)域模型采用統一個(gè)類(lèi)型，采用EntityFramework進(jìn)行持久化。

這種設計毫無(wú)疑問(wèn)對這個(gè)類(lèi)型是有侵入性的，即使采用了POCO，如果需要延時(shí)加載，也只能做到編譯時(shí)的POCO，運行時(shí)還是會(huì )生成代理類(lèi)型，某些成員需要生命為virtual，你還需要記得默認構造方法和屬性的setter都會(huì )被EntityFramework在重建對象時(shí)候調用。一個(gè)類(lèi)型承擔了兩個(gè)角色，就要完成兩份職責（持久化和封裝業(yè)務(wù)邏輯），這或許違背了單一職責原則，不過(guò)某些情況下這是最好的選擇了。

四個(gè)角色采用一個(gè)類(lèi)型

這種設計適合業(yè)務(wù)邏輯不是很復雜的場(chǎng)景，系統中只有CRUD，以四色原型為例，PPT和Des適合采用這種模式。因為這個(gè)類(lèi)型要承擔四個(gè)角色，所以沒(méi)辦法采用顯式的封裝技術(shù)，所有成員都是Public { get; set; }，考慮到很多動(dòng)態(tài)語(yǔ)言其實(shí)是沒(méi)法封裝的（是按照約定），或許C#開(kāi)發(fā)者可以接受這種設計，比如：雖然集合被公開(kāi)了，但是我們還是可以采用封裝集合模式，外部調用的時(shí)候要根據約定采用封裝過(guò)的接口，TDD有利于強制這種約定，示例代碼：

1 public class Order 2 { 3 public List<OrderItem> Items { get; set; } 4 5 public void AddItem(OrderItem item) {} 6 }

為視圖模型引入單獨的類(lèi)型

你采用了WCF技術(shù)，你的UI期望的數據和領(lǐng)域模型非常不匹配（也是一種阻抗不匹配），這時(shí)你就會(huì )引入視圖模型。如何構造視圖模型呢？一般來(lái)說(shuō)有兩種思路：一、用AutoMapper之類(lèi)的工具從領(lǐng)域模型映射；二、采用輕量級的框架（PetaPoco）直接從表、視圖和存儲過(guò)程返回。

今天只是大概聊了聊這樣一個(gè)想法，下一步會(huì )寫(xiě)一些Demo驗證幾種不同的組合。