[[385918]]

 前言

最近加入到一個(gè)新的團(tuán)隊(duì)，整體的框架方向是構(gòu)建業(yè)務(wù)中臺(tái)，劃分子域、上下文、需求結(jié)構(gòu)化和能力可配置，是通過(guò)領(lǐng)域驅(qū)動(dòng)，從整體上劃分業(yè)務(wù)中臺(tái)的領(lǐng)域，進(jìn)而劃分出業(yè)務(wù)中臺(tái)的具體能力中心，。本篇文章開始，將會(huì)結(jié)合自己的實(shí)際經(jīng)驗(yàn)，聊一聊DDD(領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))的應(yīng)用。這里我們主要聊以下我們經(jīng)常會(huì)用的的領(lǐng)域模型：VO、DTO、DO、PO。

領(lǐng)域模型中的實(shí)體類

領(lǐng)域模型中的實(shí)體類分為四種模型：VO、DTO、DO、PO，各種實(shí)體類用于不同業(yè)務(wù)層次間的交互，并會(huì)在層次內(nèi)實(shí)現(xiàn)實(shí)體類之間的轉(zhuǎn)化。

業(yè)務(wù)分層為：視圖層(VIEW+ACTION)、服務(wù)層(SERVICE)、持久層(DAO)，相應(yīng)各層間實(shí)體的傳遞如下：

VO (View Object)視圖對(duì)象

用于展示層，它的作用是把某個(gè)指定頁(yè)面(或組件)的所有數(shù)據(jù)封裝起來(lái)。

DTO(Data Transfer Object)數(shù)據(jù)傳輸對(duì)象

這個(gè)概念來(lái)源于J2EE的設(shè)計(jì)模式，原來(lái)的目的是為了EJB的分布式應(yīng)用提供粗粒度的數(shù)據(jù)實(shí)體，以減少分布式調(diào)用的次數(shù)，從而提高分布式調(diào)用的性能和降低網(wǎng)絡(luò)負(fù)載，但是這里，主要用于展示層與服務(wù)層之間的數(shù)據(jù)傳輸對(duì)象。

比如一張表有100個(gè)字段，那么對(duì)應(yīng)的DTO就有100個(gè)屬性(大多數(shù)情況下，DTO內(nèi)的數(shù)據(jù)來(lái)自多張表)。但是view層只需要顯示10個(gè)字段，沒(méi)有必要把整個(gè)PO對(duì)象傳遞到 client，這時(shí)我們就可以用只有這10個(gè)屬性的DTO來(lái)傳輸數(shù)據(jù)到 client，這樣也不會(huì)暴露 server 端的表結(jié)構(gòu)。到達(dá)客戶端后，如果用這個(gè)對(duì)象來(lái)對(duì)應(yīng)界面展示，那么此時(shí)它的身份就轉(zhuǎn)為 VO。

DO(Domain Object)領(lǐng)域?qū)ο?/span>

就是從現(xiàn)實(shí)世界中抽象出來(lái)的有形或無(wú)形的業(yè)務(wù)實(shí)體。

PO(Persistent Object)：持久化對(duì)象

它跟持久層(通常是關(guān)系型數(shù)據(jù)庫(kù))的數(shù)據(jù)結(jié)構(gòu)形成一一對(duì)應(yīng)的映射關(guān)系，如果持久層是關(guān)系型數(shù)據(jù)庫(kù)，那么，數(shù)據(jù)表中的每個(gè)字段就對(duì)應(yīng)PO的一個(gè)屬性。

對(duì)于以上概念的理解，可能還不能形成一種抽象化思維，我們通過(guò)一個(gè)時(shí)序圖建立模型來(lái)描述上述對(duì)象在三層架構(gòu)應(yīng)用中的位置：

• 用戶提交請(qǐng)求(可能是填寫表單)，表單上的數(shù)據(jù)在展示層被匹配為 VO。
• 服務(wù)層把 VO 轉(zhuǎn)換為服務(wù)層對(duì)應(yīng)方法所要求的 DTO，傳送給服務(wù)層。
• 服務(wù)層首先根據(jù) DTO 的數(shù)據(jù)構(gòu)造一個(gè) DO (或重建)，調(diào)用 DO 的業(yè)務(wù)方法完成具體業(yè)務(wù)。
• 服務(wù)層把 DO 轉(zhuǎn)換為持久層對(duì)應(yīng)的 PO(一般使用 ORM 工具)，調(diào)用持久層的持久化方法，把 PO 傳遞給它，完成持久化操作。

對(duì)于一個(gè)逆向操作，如讀取數(shù)據(jù)，也是用類似的方式轉(zhuǎn)換和傳遞。

VO 與 DTO 對(duì)比

VO 與 DTO 的區(qū)別

在這里我們可能會(huì)問(wèn)：既然 DTO 是展示層與服務(wù)層之間傳遞數(shù)據(jù)的對(duì)象，為什么還要一個(gè) VO 呢?

是的，對(duì)于絕大部分的應(yīng)用場(chǎng)景來(lái)說(shuō)，DTO 和 VO 的屬性值基本是一致的，而且他們通常都是 POJO，因此沒(méi)必要多此一舉。但不要忘記這是實(shí)現(xiàn)層的思維，對(duì)于設(shè)計(jì)層面來(lái)說(shuō)，概念上還是應(yīng)該存在 VO 和 DTO，因此兩者有著本質(zhì)的區(qū)別，DTO 代表服務(wù)層需要接收的數(shù)據(jù)和返回的數(shù)據(jù)，而 VO 代表展示層需要顯示的數(shù)據(jù)。

用一個(gè)例子來(lái)說(shuō)明可能會(huì)比較容易理解：

例如：Service 層有一個(gè) getUser 的方法返回一個(gè)系統(tǒng)用戶，其中有一個(gè)屬性是 gender(性別)，對(duì)于 Service 層來(lái)說(shuō)，它只從語(yǔ)義上定義：1-男性、2-女性、0-未指定，而對(duì)于展示層來(lái)說(shuō)，它可能需要用“帥哥”代表男性、“美女”代表女性、“秘密”代表未指定。

說(shuō)到這里，可能你還會(huì)反駁，在服務(wù)層直接返回“帥哥、美女”不就行嗎?對(duì)于大部分應(yīng)用來(lái)說(shuō)，這不是問(wèn)題，但設(shè)想以下，如果需求允許客戶可以定制風(fēng)格，而不同的客戶端對(duì)于表現(xiàn)層的要求有所不同，那么，問(wèn)題就來(lái)了。再者，回到設(shè)計(jì)層面分析，從職責(zé)單一原則來(lái)看，服務(wù)層只負(fù)責(zé)業(yè)務(wù)，與具體的表現(xiàn)形式無(wú)關(guān)，因此，它返回的 DTO，不應(yīng)該出現(xiàn)與表現(xiàn)形式的耦合。

理論歸理論，這到底還是分析設(shè)計(jì)層面的思維，是否在具體實(shí)現(xiàn)層面必須這樣做呢?一刀切的做法往往會(huì)得不償失，下面我們具體分析應(yīng)用中如何做出正確的選擇。

VO 與 DTO 的應(yīng)用

在上面只是用了一個(gè)簡(jiǎn)單的例子來(lái)說(shuō) VO 與 DTO 在概念上區(qū)別，這里我們具體分析在應(yīng)用中如何做出正確的選擇。

在以下場(chǎng)景中，我們可以考慮把 VO 與 DTO 合二為一(注意：是實(shí)現(xiàn)層面)：

• 當(dāng)需求非常清晰穩(wěn)定，而且客戶端很明確只有一個(gè)的時(shí)候，沒(méi)有必要把 VO 和 DTO 區(qū)分開來(lái)，這時(shí)候 VO 可以隱退，用一個(gè) DTO 即可，為什么是 VO 隱退而不是 DTO ?回到設(shè)計(jì)層面，服務(wù)層的職責(zé)依然不應(yīng)該與展示層耦合，所以對(duì)于前面的例子，你很容易理解，DTO 對(duì)于 “性別”來(lái)說(shuō)，依然不能用“帥哥美女”，這個(gè)轉(zhuǎn)換應(yīng)該依賴于頁(yè)面的腳本(如 JavaScript)或其他機(jī)制(JSTL、EL、CSS)。
• 即使客戶端可以進(jìn)行定制，或者存在多個(gè)不同的客戶端，如果客戶端能夠用某種技術(shù)(腳本或其他機(jī)制)實(shí)現(xiàn)轉(zhuǎn)換，同樣可以讓VO隱退。

以下場(chǎng)景需要優(yōu)先考慮 VO、DTO 并存：

• 因?yàn)槟撤N技術(shù)原因，比如某個(gè)框架(如Flex)提供自動(dòng)把 POJO 轉(zhuǎn)換為 UI 中某些 Field 時(shí)，可以考慮在實(shí)現(xiàn)層面定義出 VO，這個(gè)權(quán)衡完全取決于使用框架的自動(dòng)轉(zhuǎn)換能力帶來(lái)的開發(fā)和維護(hù)效率提升與設(shè)計(jì)多一個(gè)VO所多做的事情帶來(lái)的開發(fā)和維護(hù)效率的下降之間的比對(duì)。
• 如果頁(yè)面出現(xiàn)一個(gè)“大視圖”，而組成這個(gè)大視圖的所有數(shù)據(jù)需要調(diào)用多個(gè)服務(wù)，返回多個(gè)DTO來(lái)組裝(當(dāng)然，這同樣可以通過(guò)服務(wù)層提供一次性返回一個(gè)大視圖的DTO來(lái)取代，但在服務(wù)層提供一個(gè)這樣的防腐是否合適，需要在設(shè)計(jì)層面進(jìn)行權(quán)衡)。

DTO 與 DO 對(duì)比

DTO 與 DO 的區(qū)別

首先是概念上的區(qū)別，DTO 是展示層和服務(wù)層之間的數(shù)據(jù)傳輸對(duì)象(可以認(rèn)為是兩者之間的協(xié)議)，而 DO 是對(duì)現(xiàn)實(shí)世界各種業(yè)務(wù)角色的抽象，這就引出了兩者在數(shù)據(jù)上的區(qū)別。

例如：UserInfo 和 User ，對(duì)于一個(gè) getUser 方法來(lái)說(shuō)，本質(zhì)上它永遠(yuǎn)不應(yīng)該返回用戶的密碼，因此 UserInfo 至少比 User 少一個(gè) password 的數(shù)據(jù)。而在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，DO不是簡(jiǎn)單的POJO，它具有領(lǐng)域業(yè)務(wù)邏輯。

DTO 與 DO 的應(yīng)用

從上面會(huì)反向問(wèn)題：既然 getUser 方法返回的 UserInfo 不應(yīng)該包含 password，那么就不應(yīng)該存在 password 這個(gè)屬性定義，但是如果同時(shí)有一個(gè) createUser 的防腐，傳入的UserInfo需要包含用戶的 password，怎么辦?

在設(shè)計(jì)層面，展示層向服務(wù)層傳遞的 DTO 與 服務(wù)層返回給展示層的 DTO 在概念上是不同的，但在實(shí)現(xiàn)層面，我們通常很少會(huì)這樣做(定義兩個(gè) UserInfo，甚至更多)，因?yàn)檫@樣做并不見得很明智，我們完全可以設(shè)計(jì)一個(gè)完全兼容的DTO，在服務(wù)層接收數(shù)據(jù)的時(shí)候，不應(yīng)該由展示層設(shè)置的屬性(如訂單的蹤跡應(yīng)該由其單價(jià)、數(shù)量、折扣等決定)，無(wú)論展示層是否設(shè)置，服務(wù)層都一概忽略，而在服務(wù)層返回?cái)?shù)據(jù)時(shí)，不該返回的數(shù)據(jù)(如用戶密碼)，就不設(shè)置對(duì)應(yīng)的屬性。

對(duì)于DO來(lái)說(shuō)，還有一點(diǎn)需要說(shuō)明：為什么不在服務(wù)層中直接返回 DO 呢?這樣可以省去 DTO 的編碼和轉(zhuǎn)換工作，原因如下：

• 兩者在本質(zhì)上的區(qū)別可能導(dǎo)致彼此并不一一對(duì)應(yīng)，一個(gè)DTO可能對(duì)應(yīng)多個(gè)DO，反之亦然，甚至兩者存在多對(duì)多的關(guān)系;
• DO 具有一些不應(yīng)該讓展示層知道的數(shù)據(jù);
• DO 具有業(yè)務(wù)方法，如果直接把 DO 傳遞給展示層，展示層的代碼就可以繞過(guò)服務(wù)層直接調(diào)用它不應(yīng)該訪問(wèn)的操作，對(duì)于基于 AOP 攔截服務(wù)層來(lái)進(jìn)行訪問(wèn)控制的機(jī)制來(lái)說(shuō)，這問(wèn)題尤其突出，而在展示層調(diào)用DO的業(yè)務(wù)方法也會(huì)因?yàn)槭挛锏膯?wèn)題，讓事物難以控制。
• 對(duì)于某些ORM框架(如Hibernate)來(lái)說(shuō)，通常會(huì)使用“延遲加載”技術(shù)，如果直接把 DO 暴露給展示層，對(duì)于大部分情況，展示層不在事物范圍之內(nèi)(Open session in view 在大部分情況下不是一種值得推崇的設(shè)計(jì))，如果其嘗試在Session關(guān)閉的情況下獲取一個(gè)未加載的關(guān)聯(lián)對(duì)象，會(huì)出現(xiàn)運(yùn)行時(shí)異常(對(duì)于Hibernate來(lái)說(shuō)，就是 LazyInitliaztionException);
• 從設(shè)計(jì)層面來(lái)說(shuō)，展示層依賴于服務(wù)層，服務(wù)層依賴于領(lǐng)域?qū)樱绻袲O暴露出去，就會(huì)導(dǎo)致展示層直接依賴于領(lǐng)域?qū)樱@雖然依然單向依賴，但這種跨層依賴會(huì)導(dǎo)致不必要的耦合。

對(duì)于DTO來(lái)說(shuō)，也有一點(diǎn)必須進(jìn)行說(shuō)明，就是DTO應(yīng)該是一個(gè)“扁平的二維對(duì)象”舉個(gè)例子：

• 如果User 會(huì)關(guān)聯(lián)若干個(gè)其他實(shí)體(例如 Address、Account、Region等)，那么 getUser() 返回的 UserInfo，是否就需要把其關(guān)聯(lián)的對(duì)象的 DTO 都一并返回呢?如果這樣的話，必然導(dǎo)致數(shù)據(jù)傳輸量的大增，對(duì)于分布式應(yīng)用來(lái)說(shuō)，由于涉及數(shù)據(jù)在網(wǎng)絡(luò)上傳輸、序列化和反序列化，這種設(shè)計(jì)更不可接受。
• 如果getUser除了要返回User的基本信息外，還需要返回一個(gè)AccountId、AccountName、RegionId、RegionName，那么，請(qǐng)把這些屬性定義到UserInfo中，把一個(gè)“立體”的對(duì)象樹“壓扁”成一個(gè)“扁平的二維對(duì)象”。

DO 與 PO 對(duì)比

DO 與 PO 的區(qū)別

DO 和 PO 在絕大部分情況下是一一對(duì)應(yīng)的，PO是只含有 get/set 方法的POJO，但某些場(chǎng)景還是能反映出兩者在概念上存在本質(zhì)區(qū)別：

• DO 在某些場(chǎng)景下不需要進(jìn)行顯式的持久化，例如利用策略模式設(shè)計(jì)的商品折扣策略，會(huì)衍生出折扣策略的接口和不同折扣策略實(shí)現(xiàn)類，這些折扣策略實(shí)現(xiàn)類可以算是 DO，但它們只會(huì)駐留在靜態(tài)內(nèi)存池，不需要持久化到持久層，因此，這類 DO 是不存在對(duì)應(yīng)的 PO的。
• 同樣的道理，某些場(chǎng)景下，PO也沒(méi)有對(duì)應(yīng)的DO，例如老師Teacher和學(xué)生Student存在多對(duì)多的關(guān)系，在關(guān)系數(shù)據(jù)庫(kù)中，這種關(guān)系需要表現(xiàn)為一個(gè)中間表，也就對(duì)應(yīng)有一個(gè)TeacherAndStudentPO的PO，但這個(gè)PO在業(yè)務(wù)領(lǐng)域沒(méi)有任何現(xiàn)實(shí)的意義，它完全不能與任何DO對(duì)應(yīng)上。

這里要特別聲明，并不是所有多對(duì)多關(guān)系都沒(méi)有業(yè)務(wù)含義，這跟具體業(yè)務(wù)場(chǎng)景有關(guān)，例如：兩個(gè)PO之間的關(guān)系會(huì)影響具體業(yè)務(wù)，并且這種關(guān)系存在多種類型，那么這種多對(duì)多關(guān)系也應(yīng)該表現(xiàn)為一個(gè)DO，又如：“角色”與“資源”之間存在多對(duì)多關(guān)系，而這種關(guān)系很明顯會(huì)表現(xiàn)為一個(gè)DO——“權(quán)限”。

某些情況下，為了某種持久化策略或者性能的考慮，一個(gè)PO可能對(duì)應(yīng)多個(gè)DO，反之亦然。例如客戶Customer有其聯(lián)系信息Contacts，這里是兩個(gè)一對(duì)一關(guān)系的DO，但可能出于性能的考慮(極端情況，權(quán)作舉例)，為了減少數(shù)據(jù)庫(kù)的連接查詢操作，把Customer和Contacts兩個(gè)DO數(shù)據(jù)合并到一張數(shù)據(jù)表中。反過(guò)來(lái)，如果一本圖書Book，有一個(gè)屬性是封面cover，但該屬性是一副圖片的二進(jìn)制數(shù)據(jù)，而某些查詢操作不希望把cover一并加載，從而減輕磁盤IO開銷，同時(shí)假設(shè)ORM框架不支持屬性級(jí)別的延遲加載，那么就需要考慮把cover獨(dú)立到一張數(shù)據(jù)表中去，這樣就形成一個(gè)DO對(duì)應(yīng)多個(gè)PO的情況。 PO的某些屬性值對(duì)于DO沒(méi)有任何意義，這些屬性值可能是為了解決某些持久化策略而存在的數(shù)據(jù)，例如為了實(shí)現(xiàn)“樂(lè)觀鎖”，PO存在一個(gè)version的屬性，這個(gè)version對(duì)于DO來(lái)說(shuō)是沒(méi)有任何業(yè)務(wù)意義的，它不應(yīng)該在DO中存在。同理，DO中也可能存在不需要持久化的屬性。

DO 與 PO 的應(yīng)用

由于ORM框架的功能非常強(qiáng)大而大行其道，而且JavaEE也推出了JPA規(guī)范，現(xiàn)在的業(yè)務(wù)應(yīng)用開發(fā)，基本上不需要區(qū)分DO與PO，PO完全可以通過(guò)JPA，Hibernate Annotations/hbm隱藏在DO之中。雖然如此，但有些問(wèn)題我們還必須注意：

• 對(duì)于DO中不需要持久化的屬性，需要通過(guò)ORM顯式的聲明，如：在JPA中，可以利用@Transient聲明。
• 對(duì)于PO中為了某種持久化策略而存在的屬性，例如version，由于DO、PO合并了，必須在DO中聲明，但由于這個(gè)屬性對(duì)DO是沒(méi)有任何業(yè)務(wù)意義的，需要讓該屬性對(duì)外隱藏起來(lái)，最常見的做法是把該屬性的get/set方法私有化，甚至不提供get/set方法。但對(duì)于Hibernate來(lái)說(shuō)，這需要特別注意，由于Hibernate從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)轉(zhuǎn)換為DO時(shí)，是利用反射機(jī)制先調(diào)用DO的空參數(shù)構(gòu)造函數(shù)構(gòu)造DO實(shí)例，然后再利用JavaBean的規(guī)范反射出set方法來(lái)為每個(gè)屬性設(shè)值，如果不顯式聲明set方法，或把set方法設(shè)置為private，都會(huì)導(dǎo)致Hibernate無(wú)法初始化DO，從而出現(xiàn)運(yùn)行時(shí)異常，可行的做法是把屬性的set方法設(shè)置為protected。
• 對(duì)于一個(gè)DO對(duì)應(yīng)多個(gè)PO，或者一個(gè)PO對(duì)應(yīng)多個(gè)DO的場(chǎng)景，以及屬性級(jí)別的延遲加載，Hibernate都提供了很好的支持，請(qǐng)參考Hibnate的相關(guān)資料。

總結(jié)

到目前為止，已經(jīng)比較清晰的了解VO、DTO、DO、PO的概念、區(qū)別和實(shí)際應(yīng)用了。通過(guò)上面的詳細(xì)分析，我們還可以總結(jié)出一個(gè)原則：分析設(shè)計(jì)層面和實(shí)現(xiàn)層面完全是兩個(gè)獨(dú)立的層面，即使實(shí)現(xiàn)層面通過(guò)某種技術(shù)手段可以把兩個(gè)完全獨(dú)立的概念合二為一，在分析設(shè)計(jì)層面，我們?nèi)匀?至少在頭腦中)需要把概念上獨(dú)立的東西清晰的區(qū)分開來(lái)，這個(gè)原則對(duì)于做好分析設(shè)計(jì)非常重要(工具越先進(jìn)，往往會(huì)讓我們?cè)铰槟?。