Design patterns DDD作为实体或值对象查找

我从领域驱动的开发开始，在阅读了大量的资料之后，我试图用DDD的方式重构一个应用程序。但我面临一个根本性的问题，不知道如何解决

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

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

我对对象的不变状态有点困惑。首先，我认为一个lcation必须是一个实体对象，因为它有一个标识。但在范围内，位置本身是不变的，不能改变

---

我真的很困惑。有人能帮我清除视图吗？

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

我会这样做，因为位置是有限的，你可能会想把它们建模为实体（也就是说，它们是你要存储和放置ID的对象，而不是像学生的家庭地址这样的对象，它们很可能总是值对象，因为它们没有可变性或可重用性），以location作为聚合根，每个位置都有一个address属性，该属性将是一个值对象（如果您使用的是SQL，那么地址可以被反规范化，并与位置数据一起存储在行中）

---

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

决策取决于您如何识别它们。（而不是不可修改性）

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

@Entity
Location {
    @Identifier private String code;

    //many other mutable properties
}

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

---

DDD不擅长产品信息或其他面向内容管理的领域。我宁愿保留原来的结构，但要找到一个小的子域进行重构，比如库存或定价。

类别和位置就是沃恩·弗农在书中所说的标准类型的例子。尽管本书中的讨论在第6章-价值对象中，但他建议标准类型应该是其本地BC中的一个实体，我们应该尝试将其视为消费BC中的VO：

我们可以将这些视为实体，因为它们在一个专用的、本地绑定的上下文中有自己的生命。无论它们是如何由任何一种标准机构创建和维护的，如果可能的话，我们都应该努力在我们的消费环境中将它们视为价值观。[……]

为了维护，标准类型通常本机驻留在与使用它们的模型不同的上下文中。它们是实体，具有持久的生命周期，具有标识、名称和描述等属性

（顺便说一句，Vernon提到他称之为标准类型的这种对象是aka lookup和type code。）