[toc] 軟體中所表示的模型 表示模型的3種模型元素模式：ENTITY、VALUE OBJECT和SERVICE。從錶面上看，定義那些用來捕獲領域概念的對象很容易，但要想反映其含義卻很困難。這要求我們明確區分各種模型元素的含義，並與一系列設計實踐結合起來，從而開發出特定類型的對象。 個人理解：就是 ...
目錄
軟體中所表示的模型
表示模型的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]中就從模式角度對其進行瞭解釋。
個人理解：包，關註高內聚低耦合就對了。
