问题标签 [value-objects]

我有 2 个字段 id 和 language_name 的语言表。我可以将其视为价值对象吗？

防爆记录：1 EN 2 DE 3 TR

一旦这些值是不可变的，我认为我不需要给它们 Id 并将其作为直接在数据库中表示的实体。

我从域驱动开发开始，经过大量阅读后，我试图以 DDD 方式重构应用程序。但我面临一个基本问题，不知道如何解决。

作为介绍，我的应用程序应该执行一些简化的任务。这是一个课程预订应用程序：

• 课程由类别、日期时间、描述和位置组成
• 可以从下拉框中选择类别和位置
• 一个特殊的设置部分让用户可以添加和更改类别和位置

我对对象的不可变状态有点困惑。首先，我认为例如 lcoation 必须是实体对象，因为它具有标识。但当然，在范围内，位置本身是不可变的，无法更改。

我真的很困惑。任何人都可以帮助我清除我的观点吗？

我有一个关于在下面的案例中识别值对象以及我必须如何实现它的问题。

案子：

在在线社区中，用户可以创建自己的私人/公共页面（例如 Facebook）。在此页面中，他们可以发布帖子等。这些帖子可以由其他用户评分。不仅帖子可以评分，而且整个页面都可以被其他用户评分。

因此，如果我尝试对此进行建模，我最终会得到 3 个实体（页面、用户、帖子），它们在此内容中都有唯一的身份。但是收视率呢？我倾向于使用价值对象，因为评级在此内容中没有足够的身份（没有它可以存在帖子或页面）并且没有用户就无法存在。

问题：它是一个值对象还是一个实体:)

谢谢！

我有一个名为 Schoolyear 的业务对象，目前有一个 flags 枚举：

对我来说，这是没有标识符的值对象，它们没有额外的 sql 表。这也将是矫枉过正。

现在我考虑将这些可见日期（用户可以配置）保存为数据库中的 int 值。它目前可以工作，但是在数据库中读/写并将这些值读/写到业务对象中并与该对象进行集成测试是很痛苦的。

因为我有一个使用 json 数据的 javascript 客户端，所以今天早上我想为什么不将我从浏览器直接获取的 json 数组保存为数据库中的 json 字符串。所以我唯一要做的就是客户端的 json.parse 。为了在服务器端进行集成测试，我使用了 json 库中现有的 json.serialize/deserialize 方法。

可见天数在一年中仅更改 1,2 或 3 次，并不经常。每个用户每 5 年有 5 个学年数据行可能不多。永远不会通过 sql select 查询可见天数列。UI 逻辑在客户端完成。

所以对我来说，将 json 数组作为 json 字符串存储在 sql 数据库中是一个好主意。

你觉得我的新方法怎么样？你有没有看到我没有想到的任何负面影响，我以后可以再次悔改......？

我正在尝试结合一些技术。

永远不要创建无效的 ValueObject 似乎是一种很好的做法。每当提供的内容不足以创建有效的 ValueObject 时，ValueObject 构造函数就会失败。在我的示例中，只有存在值时才能创建 EmailAddress 对象。到目前为止，一切都很好。

验证所提供电子邮件地址的值，这就是我开始怀疑这些原则的地方。我有四个例子，但我不知道哪一个应该被认为是最佳实践。

示例 1 很简单：只是一个构造函数、一个必需的参数“值”和一个单独的函数 validate 以保持代码清洁。所有的验证码都保留在类中，并且永远不会被外界使用。该类只有一个目的：存储电子邮件地址，并确保它永远不会是无效的。但是代码永远不会可重用——我用它创建了一个对象，仅此而已。

示例 2 使 validate 函数成为静态函数。该函数永远不会改变类的状态，因此它是对 static 关键字的正确使用，并且其中的代码将永远无法对嵌入静态函数的类创建的任何实例进行任何更改。但是如果我想重用代码，我可以调用静态函数。不过，这对我来说感觉很脏。

示例 3 引入了另一个类，在我的对象主体中进行了硬编码。另一个类是一个验证类，包含验证代码，因此创建了一个可以在我需要验证类时随时随地使用的类。该类本身是硬编码的，这也意味着我在该验证类上创建了一个依赖项，它应该始终在附近，而不是通过依赖项注入来注入。可以说，硬编码验证器与将完整代码嵌入对象中一样糟糕，但另一方面：DI 很重要，这样就必须创建一个新类（扩展或简单地重写）以只需更改依赖项。

示例 4 再次使用验证器类，但将其放在构造函数中。因此，我的 ValueObject 需要在创建类之前已经存在和创建的验证器类，但可以轻松地覆盖验证器。但是对于一个简单的 ValueObject 类在构造函数中具有这样的依赖关系有多好，因为唯一真正重要的是值，如果电子邮件正确，我不应该知道如何以及在哪里处理，并提供一个正确的验证器。

我开始考虑的最后一个示例是提供默认验证器，同时可以通过 DI 为构造函数中的验证器注入覆盖。但是当您覆盖最重要的部分：验证时，我开始怀疑一个简单的 ValueObject 有多好。

所以，任何人都有一个答案，应该以哪种方式编写这个类最好，这对于像电子邮件地址这样简单的东西，或者像条形码或签证卡这样更复杂的东西或任何人们可能想到的东西都是正确的，并且不违反 DDD , DI, OOP, DRY, 错误使用静态等等...

完整代码：

最近遇到了不可变对象的概念，我想知道控制对状态的访问的最佳实践。尽管我大脑中面向对象的部分让我想在看到公众成员时畏缩不前，但我认为这样的事情没有技术问题：

将字段声明为并为每个字段提供 getter 方法我会感觉更舒服private，但是当状态显式只读时，这似乎过于复杂。

提供对不可变对象状态的访问的最佳实践是什么？

我有一个与松耦合 OOP 设计有关的问题。考虑我们有一个简单的值对象，比如 Email

}

在我想实际实现 isValid 方法之前，一切都很简单明了。我在这里有两个选择：

1）实现我自己的验证逻辑，这可能非常难看，如下所示：

2）使用一些内置的框架验证器

我真的不想遵循第一种方式，因为我不想重新发明轮子，也不想重复代码，所以我坚持第二种方式。

如果我遵循第二种方式，我就会遇到问题——我的类正在依赖于另一个框架类。

我的实际问题是在简单的情况下是否可以直接在实体/值对象中使用低级基础设施类而不使用依赖注入？

如果我“正确”地实现这个例子，代码会变得更加复杂，只是为了实现松散耦合。我必须创建一个 EmailFactory，它会为我的值对象 (Email) 类提供一个预配置的 EmailValidator 实例，该实例将在 isValid 函数中使用……</p>

我有一个聚合根“汽车”汽车有一个包含“车轮”对象的值对象“车轮”列表。由于没有轮子的汽车不应该存在（至少根据我们的业务逻辑），为了构建汽车，这在适当的领域驱动设计中是否有效：

我的问题基本上是，在聚合根之外实例化值对象以构造聚合根（在构造函数中传递值对象）是否是一种好习惯。我不想在无效状态下创建聚合根，并希望遵循最佳实践。如果上面的代码不是最佳实践，应该怎么做？

我的销售模块中有Order和类，该类用于一些分类目标并在s 上应用一些业务规则。每个班级都有自己的桌子。OrderTypeOrderTypeOrder

我想DDD在我的项目中应用技术。所以，我认为这Order是一个聚合根，但是呢OrderType？它是否也包含在Order聚合中，还是一个Value 对象？我认为这将是一个价值对象。我对么？

我正在将一个大型经典 ASP Web 应用程序转换为具有域驱动设计的 ASP.Net MVC。虽然我的大部分领域都非常适合 DDD，但我一直遇到不适合纯 DDD 方法的情况。例如，我的应用程序的读取端与写入端有很大不同。没问题，我创建了一个单独的读取模型，并实现了 CQRS 的简化版本（没有事件源，没有单独的数据库）。另一个问题是批量数据库操作。没问题，这是作为服务实现的。这是我目前的困境。我们的系统允许用户对系统进行更改，这些更改在未来某个日期生效。为了适应这一点，我们有一个数据库表，用于存储在生效日期之前的未决更改。在生效日期，自动任务运行并执行实际的数据库更新。更新任务可以包含域逻辑，因此该部分适合 DDD 并且不是问题。为了帮助可视化正在发生的事情，这里是处理挂起更新的类：

如您所见，这是一个通用类，可以处理对各种数据库表的更新。它主要存储正在更新的数据库列、该列的新值、它所属的表、生效日期和一些日志记录数据。

所以这是我的问题：收集挂起更新并将其存储在挂起更新表中的逻辑应该建模为域对象还是应该以其他方式处理，例如作为服务？

换句话说，PendingChanges 本身就是一个具有自己领域逻辑的领域实体？有一些适用于 PendingChanges 的业务规则与发生更改的实体不同。例如，构成 UserArea 的内容可以被视为业务规则，就像 FromTable 的合法值一样，更不用说验证了。

还是 PendingChanges 是一个值对象，因为它可以跨不同的域对象重用？如果是这种情况，使用 PendingUpdatesService 是否更有意义？