我目前正在設計一個使用DDD方法的Web應用程序。在區分實體和價值對象的同時，我遇到了一個這樣的模型元素，我無法決定將它放在Entity/VO類別下。應該評論歷史是一個實體，DDD
每個訂單將與1個且僅有1個管理評論列表的評論歷史記錄對象相關聯。現在，當編輯訂單時，用戶可以添加評論。這會附加到評論歷史。
評論對於持久性來說，歷史對象本身並不意味着什麼。我正在計劃使用nHibernate「組件」，所以只有註釋列表被寫到ORDER_COMMENTS表中。
訂單是一個實體。
應該評論歷史記錄（附加到訂單的各種用戶評論）是一個實體還是VO？
從我的角度來看，我將評論歷史看作價值對象，我的意思是評論歷史只是給定時間的評論集合。儘管每次添加評論時都可以重建評論歷史，但它沒有自己的身份和生命週期。
我的意思是如果你必須評論具有相同評論的歷史，我們有兩個不同的評論歷史？我不這麼認爲，我們有相同的評論歷史，我們不關心我們關心這些屬性的身份，即評論歷史中的評論是相同的。
因此，對我來說，評論歷史是V.O.
由於 巴勃羅
CommentHistory是一個實體。
因爲您在其中添加註釋而不是每次更改時都會替換整個歷史記錄。
這意味着 - 它是可修改的。
如果它是可修改的，它必須有一個身份，一個已知的「掛鉤」，你「掛起」的狀態改變。
如果它的身份，其是獨立於狀態，it's an entity：
實體：
不是由它的屬性來定義，而是由連續性和其身份的一個線程的對象。
相反，值對象由其狀態標識。如果他們被國家所識別，那麼，如果國家發生了變化，那麼這已經是一個不同的對象。對象改變自己的身份的能力太大，最終會導致混亂。這導致了價值對象應該是不可變的結論（它們的狀態每個結構只定義一次）。
再舉一例：
假設Citizen就像評論。公民被「附加」到Country。如果國家是一個價值對象，每當新生公民出生，整個國家就需要重建。
註釋是對於上述的所有原因值類型。
CommentHistory是訂單的屬性，不需要單獨的對象。它只是一個評論值的集合。訂單在內部維護集合並通過AddComment方法控制訪問。
最後一個例子很有趣，但很有趣。所有你說的都是對的，這也正是埃文斯在他的書中所說的，但是如果我們查看歷史評論的持久性方面，我只會將註釋附加到ORDER_COMMENTS表中。我在Hibernate中使用什麼構造來處理Comment History對象，一個實體封裝註釋？ – Gopal 2011-04-20 12:26:56
@GeorgeKT我個人不會打擾那麼多，只是讓流利的nhibernate自動映射，並有瘦的表CommentHistory。當涉及到持久性時，我很粗略。 :) – 2011-04-20 12:42:52
@GeorgeKT btw，類比是危險的（國家例子）。他們非常適合強調某些東西，但是如果你從中得出了強有力的結論，那就有點邪惡了。我們無法模擬現實世界 - 這是不可能的。當我們面對悖論時，我們會非常快地搞砸。非理性本質上是這個世界的一部分。我們只是針對特定問題建模解決方案。 – 2011-04-20 22:24:28