DDD - 值对象与数据对象 实体对象

发布于 2024-07-13 02:34:53 字数 74 浏览 14 评论 0原文

我是 DDD 新手,正在努力理解一些概念。 您如何确定在您的域中哪些对象是实体对象,哪些对象是值对象,以及它们到底是如何区别对待的?

I'm new to DDD and trying hard to understand some of the concepts. How do you determine in your domain what objects are Entity objects and which ones are Value objects, and how exactly are they treated differently?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

星星的軌跡 2024-07-20 02:34:54

在我看来,域对象基本上代表业务领域的名词,并且具有身份,而值对象对业务没有任何特殊含义(想想 MonetaryAmount),并且没有身份。

As I see it domain objects basically represent nouns of your business domain and do have an identity, whereas value objects do not carry any special meaning to the business (think MonetaryAmount) and do not have an identity.

野味少女 2024-07-20 02:34:53

来自 Jak Charlton 的博客

实体“这是我的实体,有很多类似的实体,但这个是
我的”

实体的关键定义特征是它具有
身份——它在系统内是唯一的,没有其他实体,没有
无论同一个实体多么相似,除非它具有相同的身份。

身份可以在实体上以多种方式表示 - 它可以是一个
数字标识符(经典的 CustomerID),它可以是一个 Guid(
经典......哦没关系),或者它可能是一个自然键(就像
CustomerNumber 您的客户是由您的 CRM 系统在他们
首先从你那里购买)。

无论您选择哪种方式表示它,实体都由以下方式定义
拥有身份。

值对象 值对象的关键定义特征是
它没有身份。 好吧,也许有点简单,但是
值对象的目的是通过它的值来表示某些东西
仅属性。 两个 VO 可能具有相同的属性,在这种情况下
它们是相同的。 然而,除了通过
凭借他们的属性。

VO 的另一个共同点是它们可能应该是
不可变,一旦创建就无法更改或更改。 你可以
创建一个新的,因为他们没有身份,所以都是一样的
就像改变另一个一样。

考虑汽车工厂系统应用程序中 POO 中的汽车类(无牌照)。 即使两辆车相同(相同的型号、发动机、颜色、重量等),每辆车都是独一无二的,并且可以通过身份来区分 车辆识别号码

两辆车可以相等,因为其属性 Car1.equals(Car2),但不能是同一辆车,因为其 VIN Car1 != Car2。 如果一辆汽车改变了颜色,那么它就不是其他汽车,而是具有其他属性的同一辆车。 这是一个实体。

现在考虑具有 nameRGB 字段的颜色类(对于汽车)。 青色的名称为 'Cyan',并且 R = 0 G = 255 B = 255。 不需要其他身份字段,因为它的属性就是它的身份。 颜色是一个 VO,并且必须是不可变的,因为更改名称或 RBG(或两者)代表其他颜色...或者在这种情况下,如果名称和 RGB 不匹配,则会出现错误;)

Color1.equals(Color) 和 Color1 == Color2 必须始终具有相同的结果。

From Jak Charlton's blog:

Entities “this is my Entity, there are many like it, but this one is
mine”

The key defining characteristic of an Entity is that it has an
Identity – it is unique within the system, and no other Entity, no
matter how similar is the same Entity unless it has the same Identity.

Identity can be represented in many ways on an Entity – it could be a
numeric identifier (the classic CustomerID), it could be a Guid (the
classic … oh never mind), or it could be a natural key (like the
CustomerNumber your Customer was given by your CRM system when they
first bought from you).

Whichever way you choose to represent it, an Entity is defined by
having an Identity.

Value Objects The key defining characteristic of a Value Objects is
that it has no Identity. Ok, perhaps a little simplistic, but the
intention of a Value Object is to represent something by it’s
attributes only. Two VOs may have identical attributes, in which case
they are identical. They don’t however have any value other than by
virtue of their attributes.

Another aspect common to VOs is that they should probably be
immutable, once created they cannot be changed or altered. You can
create a new one, and as they have no identity, that is just the same
as changing another one.

Think in a Car Class in POO in a car factory system application (no plate). Every car is unique even if the 2 cars are equals (same model, engine, color, weight, etc) and can be differentiated by a identity Vehicle Identification Number.

Two cars can be equals because its attributes Car1.equals(Car2) but not the same car because its VIN Car1 != Car2. If a car change its color it is no other car, it is the same car with other attributes. This is a Entity.

Now think in Color Class (for the car) with name and RGB fields. Cyan color has 'Cyan' in name and R = 0 G = 255 B = 255. No other identity field is needed because its atributes are its identity. Color is a VO and must be inmutable becuase changing name or RBG (or both) represent other color... or a bug in this case if name and RGB doesn't match ;)

Color1.equals(Color) and Color1 == Color2 must always have the same result.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文