DDD查找为实体或值对象

Question

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

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

• 一门课程包括类别，日期时间，描述和位置
• 可以从下拉框中选择类别和位置
• 一个特殊的设置部分使用户可以添加和更改类别和位置

我对对象的不可变状态有些困惑。 首先，我认为例如，装饰必须是一个实体对象，因为它具有身份。 但是，当然，位置本身是不可变的，无法更改。

我真的很困惑 有人可以帮助我清除我的观点吗？

Answer 1

如果可以独立于课程（添加，编辑，删除等）来管理位置，则位置很可能是独立的聚合根。 您将更改课程以引用其位置的ID，而不是包含位置。

我会这样做的，因为位置有限，所以您可能希望将它们建模为实体（即，它们是您要存储并放置ID的对象，而不是像学生的家庭住址，它很可能始终是值对象，因为它们没有可变性或可重用性，并且位置为聚合根，每个位置都有一个地址属性，该属性将是值对象（如果您使用的是SQL，则地址可以去归一化并与位置数据一起存储在行中）。

如果您不希望开发人员能够修改位置的任何属性，则可以设计类以防止修改。

Answer 2

决定依据的是您如何识别它们。

位置通常是一个实体。 但是在某些情况下，如果只关心标识符，则值对象也可以。

@Entity
Location {
    @Identifier private String code;

    //many other mutable properties
}

@ValueObject
Location {
    private String code;//the only property
}

DDD不适用于产品信息或其他面向内容管理的领域。 我宁愿保留原始结构，而是找到一个小的子域来进行重构，例如库存或定价。

Answer 3

类别和位置是沃恩·弗农（Vaughn Vernon）在他的《 实现域驱动的设计》一书中称为标准类型的示例。 尽管本书中的讨论是在第6章-值对象中，但他建议标准类型应该是其本机BC中的实体，我们应该尝试在使用BC中将它们视为VO：

我们可以将它们视为实体，因为它们在专用的本地有界上下文中拥有自己的生活。 不管任何形式的标准机构如何创建和维护它们，在可能的情况下，我们都应努力将其视为消费环境中的价值观。 [...]

为了维护起见，标准类型通常固有地驻留在与使用它们的模型不同的上下文中。 它们是实体，并且具有诸如标识，名称和描述之类的属性的持久生命周期。

（顺便说一句，弗农提到他称之为标准类型的这种对象又名查找和类型代码 。）