目錄

• 軟體中所表示的模型
  • 關聯
  • ENTITY（又稱為REFERENCE OBJECT）
  • 模式：VALUE OBJECT
  • SERVICE
  • MODULE（也稱為PACKAGE）

軟體中所表示的模型

表示模型的3種模型元素模式：ENTITY、VALUE OBJECT和SERVICE，從表面上看，定義那些用來捕獲領域概念的物件很容易，但要想反映其含義卻很困難，這要求我們明確區分各種模型元素的含義，并與一系列設計實踐結合起來，從而開發出特定型別的物件，

個人理解：就是物體類（entity），VALUE OBJECT（值物件，我沒懂）和服務（service），開發人員一看就懂了，

關聯

物件之間的關聯使得建模與實作之間的互動更為復雜，模型中每個可遍歷的關聯，軟體中都要有同樣屬性的機制，

一個顯示了顧客與銷售代表之間關聯的模型有兩個含義，一方面，它把開發人員所認為的兩個真實的人之間的關系抽象出來，另一方面，它相當于兩個Java物件之間的物件指標，或者相當于資料庫查詢（或類似實作）的一種封裝，

例如，一對多關聯可以用一個集合型別的實體變數來實作，但設計無需如此直接，可能沒有集合，這時可以使用一個訪問方法（accessor method）來查詢資料庫，找到相應的記錄，并用這些記錄來實體化物件，這兩種設計方法反映了同一個模型，設計必須指定一種具體的遍歷機制，這種遍歷的行為應該與模型中的關聯一致，

現實生活中有大量?多對多?關聯，其中有很多關聯天生就是雙向的，我們在模型開發的早期進行頭腦風暴活動并探索領域時，也會得到很多這樣的關聯，但這些普遍的關聯會使實作和維護變得很復雜，此外，它們也很少能表示出關系的本質，

至少有3種方法可以使得關聯更易于控制，

(1) 規定一個遍歷方向，

(2) 添加一個限定符，以便有效地減少多重關聯，

(3) 消除不必要的關聯，

盡可能地對關系進行約束是非常重要的，雙向關聯意味著只有將這兩個物件放在一起考慮才能理解它們，當應用程式不要求雙向遍歷時，可以指定一個遍歷方向，以便減少相互依賴，并簡化設計，理解了領域之后就可以自然地確定一個方向，

個人理解：上面的內容技術人員不要看啦，很難理解，我告訴你是怎么一回事，技術角度就是兩個物件的關聯關系如下：一對一（一個人一個鼻子），一對多（一個人兩個手臂），多對多（一個人報名多個課程，一個課程有多個人報名），是不是很像資料庫設計模型？

ENTITY（又稱為REFERENCE OBJECT）

開始講故事：可以不聽，因為我會用一句話總結，非常簡單，

軟體系統中的大多數?ENTITY?并不是人，也不是其通常意義上所指的?物體?或?存在?，ENTITY可以是任何事物，只要滿足兩個條件即可，一是它在整個生命周期中具有連續性，二是它的區別并不是由那些對用戶非常重要的屬性決定的，ENTITY可以是一個人、一座城市、一輛汽車、一張彩票或一次銀行交易，

一位女房東起訴了我，要求我賠償她房屋的大部分損失，訴狀上是這樣寫的：房間的墻上有很多小洞，地毯上滿是污漬，水池里的臟物散發出的腐蝕性氣體導致廚房墻皮脫落，法庭檔案認定我作為承租人應該為這些損失負責，依據就是我的名字和我當時的地址，這把我完全搞糊涂了，因為我從未去過那個被損壞的房子，

過了一會兒，我意識到這一定是認錯人了，我給原告打電話，告訴她這一點，但她并不相信我，幾個月以來，上一位租客一直在躲避她，如何才能證明我不是那個破壞她房屋的人呢？現在電話簿里只有一個Eric Evans名字，那就是我，還是電話簿成了我的救星，由于我在這所公寓里已經住了兩年，于是我問她是否還有去年的電話簿，她找到了電話簿，發現有與我同名的人（我就在那個人下面），她意識到我不是她要起訴的那個人，于是向我道歉，并答應撤銷起訴，

計算機可不會這么?足智多謀?，軟體系統中的錯誤標識將導致資料破壞和程式錯誤，

主要由標識定義的物件被稱作ENTITY[，ENTITY（物體）有特殊的建模和設計思路，它們具有生命周期，這期間它們的形式和內容可能發生根本改變，但必須保持一種內在的連續性，為了有效地跟蹤這些物件，必須定義它們的標識，它們的類定義、職責、屬性和關聯必須由其標識來決定，而不依賴于其所具有的屬性，即使對于那些不發生根本變化或者生命周期不太復雜的ENTITY，也應該在語意上把它們作為ENTITY來對待，這樣可以得到更清晰的模型和更健壯的實作，

當然，軟體系統中的大多數?ENTITY?并不是人，也不是其通常意義上所指的?物體?或?存在?，ENTITY可以是任何事物，只要滿足兩個條件即可，一是它在整個生命周期中具有連續性，二是它的區別并不是由那些對用戶非常重要的屬性決定的，ENTITY可以是一個人、一座城市、一輛汽車、一張彩票或一次銀行交易，

當一個物件由其標識（而不是屬性）區分時，那么在模型中應該主要通過標識來確定該物件的定義，使類定義變得簡單，并集中關注生命周期的連續性和標識，定義一種區分每個物件的方式，這種方式應該與其形式和歷史無關，要格外注意那些需要通過屬性來匹配物件的需求，在定義標識操作時，要確保這種操作為每個物件生成唯一的結果，這可以通過附加一個保證唯一性的符號來實作，這種定義標識的方法可能來自外部，也可能是由系統創建的任意識別符號，但它在模型中必須是唯一的標識，模型必須定義出“符合什么條件才算是相同的事物”，

在現實世界中，并不是每一個事物都必須有一個標識，標識重不重要，完全取決于它是否有用，實際上，現實世界中的同一個事物在領域模型中可能需要表示為ENTITY，也可能不需要表示為ENTITY，

個人理解：一句話，設計物體的時候最好有一個全域唯一id的屬性，相信做技術的會覺得，上面說了這么多就是這個意思，太簡單了，沒錯，就是這么簡單，關鍵是，我們有本事寫那么多的字來表述（瞎扯）嗎？

模式：VALUE OBJECT

很多物件沒有概念上的標識，它們描述了一個事務的某種特征，當一個小孩畫畫的時候，他注意的是畫筆的顏色和筆尖的粗細，但如果有兩只顏色和粗細相同的畫筆，他可能不會在意使用哪一支，如果有一支筆弄丟了，他可以從一套新筆中拿出一支同樣顏色的筆來繼續畫，根本不會在意已經換了一支筆，

問問孩子冰箱上的畫都是誰畫的，他會很快辨認出哪些是他畫的，哪些是他姐姐畫的，姐弟倆有一些實用的標識來區分自己，與此類似，他們完成的作品也有，但設想一下，如果孩子必須記住哪些線條是用哪支筆畫的，情況該有多么復雜？如果這樣的話，畫畫將不再是小孩子的游戲了，

由于模型中最引人注意的物件往往是ENTITY，而且跟蹤每個ENTITY的標識是極為重要的，因此我們很自然地會想到為每個領域物件都分配一個標識，實際上，一些框架確實為每個物件分配了一個唯一的ID，

這樣一來，系統就必須處理所有這些ID的跟蹤問題，從而導致許多本來可能的性能優化不得不被放棄，此外，人們還需要付出大量的分析作業來定義有意義的標識，還需要開發出一些可靠的跟蹤方式，以便在分布式系統或在資料庫存盤中跟蹤物件，同樣重要的是，盲目添加無實際意義的標識可能會產生誤導，它會使模型變得混亂，并使所有物件看起來千篇一律，

個人理解：VALUE OBJECT 可以理解entity去掉唯一性的id，變成了無狀態的一個物件，

VALUE OBJECT可以是其他物件的集合，在房屋設計軟體中，可以為每種窗戶樣式創建一個物件，我們可以將?窗戶樣式?連同它的高度、寬度以及修改和組合這些屬性的規則一起放到?窗戶?物件中，這些窗戶就是由其他VALUE OBJECT組成的復雜VALUE OBJECT，它們進而又被合并到更大的設計元素中，如?墻物件，

VALUE OBJECT經常作為引數在物件之間傳遞訊息，它們常常是臨時物件，在一次操作中被創建，然后丟棄，VALUE OBJECT可以用作ENTITY（以及其他VALUE）的屬性，我們可以把一個人建模為一個具有標識的ENTITY，但這個人的名字是一個VALUE，

當我們只關心一個模型元素的屬性時，應把它歸類為VALUE OBJECT，我們應該使這個模型元素能夠表示出其屬性的意義，并為它提供相關功能，VALUE OBJECT應該是不可變的，不要為它分配任何標識，而且不要把它設計成像ENTITY那么復雜，

SERVICE

有時，物件不是一個事物，在某些情況下，最清楚、最實用的設計會包含一些特殊的操作，這些操作從概念上講不屬于任何物件，SERVICE是作為介面提供的一種操作，它在模型中是獨立的，它不像ENTITY和VALUE OBJECT那樣具有封裝的狀態，SERVICE是技術框架中的一種常見模式，但它們也可以在領域層中使用，所謂SERVICE，它強調的是與其他物件的關系，與ENTITY和VALUE OBJECT不同，它只是定義了能夠為客戶做什么，SERVICE往往是以一個活動來命名，而不是以一個ENTITY來命名，也就是說，它是動詞而不是名詞，SERVICE也可以有抽象而有意義的定義，只是它使用了一種與物件不同的定義風格，SERVICE也應該有定義的職責，而且這種職責以及履行它的介面也應該作為領域模型的一部分來加以定義，操作名稱應來自于UBIQUITOUS LANGUAGE，如果UBIQUITOUS LANGUAGE中沒有這個名稱，則應該將其引入到UBIQUITOUS LANGUAGE中，引數和結果應該是領域物件，

好的SERVICE有以下3個特征，

(1) 與領域概念相關的操作不是ENTITY或VALUE OBJECT的一個自然組成部分，

(2) 介面是根據領域模型的其他元素定義的，

(3) 操作是無狀態的，

個人理解：就是面向介面的設計，提供的就是服務，

MODULE（也稱為PACKAGE）

MODULE是一個傳統的、較成熟的設計元素，每個人都會使用MODULE，但卻很少有人把它們當做模型中的一個成熟的組成部分，代碼按照各種各樣的類別進行分解，有時是按照技術架構來分割的，有時是按照開發人員的任務分工來分割的，甚至那些從事大量重構作業的開發人員也傾向于使用專案早期形成的一些MODULE，MODULE之間應該是低耦合的，而在MODULE的內部則是高內聚的，耦合和內聚的解釋使得MODULE聽上去像是一種技術指標，仿佛是根據關聯和互動的分布情況來機械地判斷它們，然而，MODULE并不僅僅是代碼的劃分，而且也是概念的劃分，一個人一次考慮的事情是有限的（因此才要低耦合），不連貫的思想和“一鍋粥”似的思想同樣難于理解（因此才要高內聚），

低耦合高內聚作為通用的設計原則既適用于各種對象，也適用于MODULE，但MODULE作為一種更粗粒度的建模和設計元素，采用低耦合高內聚原則顯得更為重要，這些術語由來已久，早在[Larman 1998]中就從模式角度對其進行了解釋，

個人理解：包，關注高內聚低耦合就對了，

標籤：領域驅動設計

上一篇：四 領域驅動設計-分離領域

下一篇：六 領域驅動設計-領域物件的生命周期