DDD學習記錄（一）
Entity
由標識定義的對象被稱作爲實體（Entity）。當一個對象由其標識（而不是屬性）區分時，那麼在模型中應該主要通過標識來確定該對象的定義。使類的定義變得簡單，並集中關注生命週期的連續性標識。定義一種區分對象的方式，這種方式與其形式和歷史無關。
- 體育場的座位號。在進行座位預定程序設計時，如果每張票都有一個座位號，那麼這個座位就是Entity，座位號就是它的標識。
- 如果是採用入場券形式入場，任何人可以隨意選擇座位，那麼，這個時候座位就不是一個Entity。這種情況下，只有座位總數纔是重要的。如果模型仍然把入場券和座位關聯起來，那麼它就是錯誤的。此時，座位不是Entity，不需要標識符
Value Object
用於描述領域的某個方面而本身沒有概念標識的對象稱爲Value Object（值對象）。對於這些對象，被實例化後，我們只關心他是什麼，不關心他是誰。
當我們只關心一個模型元素的屬性時，應把它歸類爲Value Object。Value Object應該是不可變的。不要爲它分配任何標識，而且不要把它設計成像Entity那樣複雜。
我理解的Value Object 像是對象的一個模板，只關心它的屬性框架，不需要具體到某一個。
Value Object的好處:
- 節省數據庫空間、減少對象數量
- 通信開銷低
- 共享的對象被嚴格的限制爲不可變。
Service
所謂的Service，它強調的是與其他對象的關係。它在模型中是獨立的，是作爲接口提供的一種操作。它只是定義了能夠爲客戶做什麼。
好的Service特徵：
- 與領域概念相關的操作不是Entity或Value Object的一個自然組成部分。
- 接口根據領域模型的其他元素定義的
- 操作是無狀態的
當領域中的某個重要的過程或轉換操作不是Entity或ValueObject的自然職責時，應該在模型中添加一個作爲獨立接口的操作，並將其聲明爲Service。定義接口時要使用模型語言，並且確保操作名稱是ubiquitous Language（通用語言）。此外Service應該設計爲無狀態的。
Module(也稱爲Package)
Module應該是低耦合的，而Module內部應該是高內聚的。選擇能夠描述系統的Module，並使之包含一個內聚的概念集合。這裏可以理解爲我們代碼上的包劃分，劃分的時候，儘可能的根據領域對象把合適的對象劃分到一起。
- 除非真正有必要將代碼分佈到不同的服務器上，否則就把他們實現單一概念對象的所有代碼放在同一個模塊。
- 利用打包把領域層從其他代碼中分離出來。否則，就儘可能讓領域開發人員自由的決定領域對象的打包方式，以便支持他們的模型和設計選擇。