DDD(二)——實體(Entity)

2.什麼是實體

實體就是分析需求所獲得的結果，用面向對象的說法就是經過分析需求肯定對象，這些對象有什麼做用。

好比說一個系統的使用者就是用戶，那麼用戶實體須要有惟一標識id，帳號暱稱name，登錄密碼password這些基礎屬性。

public class User（）{
	private Long id;
	private String name;
	private String password;
	get()...
	set()...
}

---

3.值對象

經過分析需求，咱們不只須要用戶實體，還須要給用戶分配角色，那麼咱們就須要在用戶實體中記錄角色id。

public class User（）{
	private Long id;
	private String name;
	private String password;
	private Long rid;
	get()...
	set()...
}

public class Role（）{
	private Long id;
	private String rname;
	get()...
	set()...
}

可是這時候需求分析出來用戶不止一個角色，那麼能夠用一箇中間表來處理。

public class UserAndRole（）{
	private Long uid;
	private Long rid;
}

這樣作是至關麻煩的，由於每次作相關修改都須要查詢三張表。DDD所提倡的方式就是將實體對象看成值的方式來處理。

public class User（）{
	private Long id;
	private String name;
	private String password;
	private List<Role> role;
	get()...
	set()...
}

這樣就能輕鬆省力，並且就方便閱讀理解。可是這並不表明這種方式是最好的選擇，若是關聯表使用次數不多，而且不多修改，其實記錄id會是更好的選擇。

值對象這一律念並非DDD中提出的，在以前就有相關的概念，傳統的值對象簡單的按照業務相關性能夠劃分爲三類指po，vo，bo。

• bo（bussiness object） -- 業務對象，業務相關性最強，每一個對象之間的邏輯關係體現爲業務的複雜性和邏輯性
• vo （value object）-- 數據對象，主要用於服務層，對bo進行拆分，使其適用代碼邏輯的東西
• po（persistent object）-- 持久化對象，和數據庫表對應的對象，用於ORM。

這樣描述太官方，簡單來講保存到數據庫中的數據有是po，若是須要將性別（0表明男，1表明女）展現在頁面上，要麼把age這個屬性變成男女這兩個漢字再傳給視圖層的對象就是vo，若是是須要對數據進行邏輯處理的實體對象就叫作bo，好比須要大於或者小於。bo和vo並非必定和po一摸同樣，能夠根據實際業務有多個vo、多個bo，理解爲傳值的對象。

4.分類

實體在DDD中也能夠稱爲領域模型，領域模型這一律念在此就很少敘述。實體的做用是什麼呢，最主要的做用就是持久化數據，以持久化爲基礎實體又劃分了4大類：

1. 失血模型
2. 貧血模型
3. 充血模型
4. 脹血模型

失血模型簡單來講，就是隻有屬性的getter/setter方法的純數據類。

貧血模型是實體不只包含了getter/setter，還包含一些簡單的邏輯。

充血模型與貧血模型相似，只是取消了持久化邏輯（dao），將其包含在了實體當中。

脹血模型就是除了充血模型所包含的，還將service層的業務放入實體當中。

DDD提倡使用充血模型實體，取消了dao，同時減輕service層的壓力。

5.小結

DDD中的實體概念上並無不同凡響，只是在選擇那種模式設計實體上與以往有差別，並無什麼創新觀點在其中，反而在業務很是複雜的時候使用充血模型會致使邏輯混亂，代碼難以閱讀的問題。