DDD：幫助我進一步瞭解價值對象和實體

有幾個關於這方面的問題，閱讀它們並沒有幫助我。在Eric Evans DDD中，他在某些情況下使用地址作爲值類型的示例。對於郵購公司來說，地址是一種價值類型，因爲地址是共享的，誰住在地址上並不重要，只要包裹到達地址即可。DDD：幫助我進一步瞭解價值對象和實體

這對我來說很有意義，直到我開始思考如何做到這一點的設計。考慮到圖99頁上，他這樣說：

+------------+ 
|Customer | 
+------------+ 
|customerId | 
|name  | 
|street  | 
|city  | 
|state  | 
+------------+

這變爲：

+------------+ 
|Customer | (entity) 
+------------+ 
|customerId | 
|name  | 
|address  | 
+------------+ 

+------------+ 
|Address  | (value object) 
+------------+ 
|street  | 
|city  | 
|state  | 
+------------+

如果這些表格，地址將有其自己的ID，纔能有與的關係客戶，把它變成一個實體。

在關係數據庫中，它們會留在同一個表中（例如在第一個示例中），並且您會使用ORM的功能將地址抽象爲值對象（如nHibernate的組件功能）？

我意識到幾頁後，他談到了非規範化，我只是想確保我正確理解概念。

來源

2011-02-15 user500038

的理念是在關係數據庫這些會留在同一個表，如在第一個例子，和你使用ORM 的功能，以抽象的地址作爲值對象（如nHibernate的組件功能）？

是，一般，就是這個想法。或者（如果你的ORM不直接支持Value Objects），你可以讓VO表有一個ID，但隱藏在你的域模型中。

來源

2011-02-15 21:35:02

我個人不給該死，只要他們正常重寫等式比較具有價值的對象ID（原因值對象不同在於它們的價值不認同）。

映射值對象數據庫技術的關注，有時（例如標記道具虛擬的，這樣可以ORM底下爬）你只需要犧牲域模型的純度位。或者讓你的基礎設施更加智能 - 使用nhib組件或其他東西。

來源

2011-02-16 13:05:28

當埃裏克埃文斯談到「實體具有身份，價值對象不會」時，他並不是在談論數據庫中的ID列 - 他在談論身份是一個概念。

虛擬組織有沒有概念上的身份。這並不意味着他們不應該有持久的身份。不要讓持久性實現影響您對實體vs VOs的理解。

可以在客戶

來源

2011-02-18 19:36:26 kamal

感謝您的解釋，這有助於我對這種情況下使用DDD感到更加自信。 – jpierson 2011-03-10 17:19:57

是的，一般地址會留在同一個表中創建單獨的表的地址或在同一個表。地址映射如下：

+-----------------+ 
|Customer   | 
+-----------------+ 
|customerId  | 
|name    | 
|address_street | 
|address_city  | 
|address_state | 
+-----------------+

如果Address是一個實體，那麼它將在一個單獨的表中，正如您所說的那樣。如果兩個相同的客戶鏈接到相同的地址實體，則更改該地址的屬性將影響兩個客戶。然而，VO實現只會影響其中一個。

來源

2011-11-03 16:19:46 chasemyaccord

DDD：幫助我進一步瞭解價值對象和實體

回答

相關問題