值与实体对象(域驱动设计)

83 domain-driven-design value-objects entityobject

我刚开始阅读DDD.我无法完全掌握Entity vs Value对象的概念.有人可以解释当Value对象被设计为Entity对象时系统可能遇到的问题(可维护性,性能等等)吗?例子很棒......

Jas*_*rue 99

减少到本质区别,身份对实体很重要,但对价值对象无关紧要.例如,某人的姓名是值对象.Customer实体可能由客户名称(值对象),List <Order> OrderHistory(实体列表)以及可能的默认地址(通常是值对象)组成.客户实体将拥有一个ID,每个订单都有一个ID,但名称不应该; 通常,在对象模型中,地址的标识可能无关紧要.

值对象通常可以表示为不可变对象; 更改值对象的一个​​属性实质上会破坏旧对象并创建一个新对象,因为您不像内容那样关注身份.正确地,只要对象的属性与另一个实例的属性相同,Name上的Equals实例方法将返回"true".

但是,更改像Customer这样的实体的某些属性不会破坏客户; 客户实体通常是可变的.身份保持不变(至少一旦对象被持久化).

您可能在没有意识到的情况下创建了值对 无论何时通过创建细粒度类来表示实体的某些方面,您都有一个值对象.例如,类IPAddress(对有效值有一些约束但由更简单的数据类型组成)将是一个值对象.EmailAddress可以是字符串,也可以是具有自己的一组行为的值对象.

甚至在数据库中具有标识的项目也很可能在对象模型中没有标识.但最简单的情况是一些有意义的属性的组合.当您可以将Customer.Name组合在一起时,您可能不希望拥有Customer.FirstName,Customer.LastName,Customer.MiddleInitial和Customer.Title; 在您考虑持久性时,它们可能是数据库中的多个字段,但您的对象模型并不关心.


Ric*_*man 31

由所有属性共同定义的任何对象都是值对象.如果任何属性发生更改,则会有一个值对象的新实例.这就是将值对象定义为不可变的原因.

如果对象未被其所有属性完全定义,则存在构成对象标识的属性子集.其余属性可以更改而无需重新定义对象.这种对象不能在immutable中定义.

一种更简单的区分方法是将值对象视为永不改变的静态数据,将实体视为应用程序中演变的数据.


Pre*_*raj 11

值类型:

  • 值类型本身不存在,取决于实体类型。
  • 值类型对象属于实体类型对象。
  • 值类型实例的生命周期受拥有实体实例的生命周期的限制。
  • 三种值类型:基本(原始数据类型)、复合(地址)和集合(映射、列表、数组)

实体:

  • 实体类型可以独立存在(Identity)
  • 实体有自己的生命周期。它可以独立于任何其他实体而存在。
  • 例如:人、组织、学院、手机、家庭等。每个对象都有自己的身份

  • 与 DDD 无关:( (4认同)

Chr*_*man 6

我不知道以下是否正确,但我会说,在Address对象的情况下,我们希望将它用作值对象而不是实体,因为对实体的更改将反映在所有链接对象上(例如一个人).

以这种情况为例:你和其他人一起住在你的房子里.如果我们使用Entity for Address,我会争辩说所有Person对象都会链接到一个唯一的Address.如果一个人搬出,你想要更新他的地址.如果要更新地址实体的属性,则所有人都将拥有不同的地址.在值对象的情况下,我们将无法编辑地址(因为它是不可变的),我们将被迫为该Person提供新的地址.

这听起来不错吗?在阅读DDD书之后,我必须说我仍然对这种差异感到困惑.

更进一步,如何在数据库中建模?您是否将Address对象的所有属性都作为Person表中的列,或者您是否会创建一个也具有唯一标识符的单独Address表?在后一种情况下,生活在同一个房子里的人每个都有一个不同的Address对象实例,但这些对象除了ID属性外都是相同的.


小智 5

地址可以是实体或值对象,具体取决于业务进程。地址对象可以是快递服务应用程序中的实体,但地址可以是其他应用程序中的值对象。在快递应用程序中,地址对象的身份很重要