2012-03-16 63 views
2

我剛開始學習領域驅動設計,和的幾件事情之一是讓我困惑的最多的是如何確定哪一個應該是實體,它應該是值對象DDD:分類實體/值對象

我知道,以確定實體/值對象,我們要立足於域範圍內,在一個方面,一個域對象可以是實體的,在另一個,它可以是值對象,但還是有一些情況下,我不能決定

.eg解決 - 在客戶管理應用程序(讓我們只說一個應用程序來管理客戶,添加/刪除/更改狀態,客戶等)的情況下,地址顯然是值對象,因爲在這裏我們並不需要一個地址來區分另一方面,2個客戶可以擁有相同的地址 - 另一方面,在線上預訂應用程序的情況下,我可以說地址是一個實體嗎?因爲現在我們需要他們的帳單地址來區分客戶(忽略的情況下2個客戶具有相同地址的時刻)

對我來說,地址是唯一的本身,所以它肯定已經有了身份。因此,域對象的身份不會決定它是一個實體還是值對象,如果是的話,那麼選擇的關鍵因素是什麼?

另外一個例子,我有一個應用程序,它列出一個國家的多個領域,用戶可以選擇一個區域,並找到所有適合他們的搜索條件在這一領域的餐館。在這種情況下,區域是一個值對象還是實體?目前我認爲它更多的是一個實體,但仍不是很確定。每個區域是唯一的也是

我不知道我的問題是清澈還是不行,我盡我所能來解釋我的想法目前

回答

6

,我認爲你的一些困難,可能是在一些微妙的含義這些條款。例如,你提到「對我來說,地址本身是獨一無二的,所以它肯定有身份」。就大多數人在領域驅動設計中如何使用「身份」而言,您的陳述可能不正確。

值對象的屬性集的是其定義。如果你改變它的任何方面,你有一個完全不同的對象。使用你的地址例子,如果你改變了它的任何部分,你會得到一個完全不同的地址。它是不是與它的方面改變了相同的地址。您的客戶轉移到新地址;他們沒有改變同一地址的方面。

但是,如果您是映射應用程序,並且地址本身已更改,則此處的地址將是實體。在這種情況下,城市規劃人員可能希望重新在街道上重新編號。在這種情況下,同一地址正在被修改。在這種情況下,我們需要更新實體,而不是值對象。

關於你的帳單地址例如,賬單地址很可能還是一個價值實體(至少是它的物理地址部分)。在該例子中,支付方法(例如信用卡)可以是實體,並且可以包括其他值對象(例如帳單地址,信用卡號碼等)。

您可能會發現它有用看到檢討這個問題,它的答案,以及:Value vs Entity objects (Domain Driven Design)

希望這有助於。祝你好運!

+2

非常感謝你,你的解釋是我正在尋找的東西,現在一切都更清晰 – 2012-03-19 15:42:47

+0

謝謝,Phuong,很高興它幫助。 – 2012-03-19 21:16:05