0

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

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

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

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

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

4

3 回答 3

0

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

我会这样做，因为位置是有限的，您可能希望将它们建模为实体（即它们是您想要存储和放置 id 的东西，而不是像学生的家庭住址之类的东西，这很可能总是值对象，因为它们没有可变性或可重用性），位置作为聚合根，每个位置都有一个地址属性，该属性将是一个值对象（如果您使用的是 SQL，那么地址可以非规范化并与位置数据一起存储）。

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

于 2013-11-22T12:52:41.943 回答
0

决定取决于您如何识别它们。（不是不变性）

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

@Entity
Location {
    @Identifier private String code;

    //many other mutable properties
}

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

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

于 2013-11-23T01:44:01.947 回答
0

类别和位置是 Vaughn Vernon 在其《实现领域驱动设计》一书中所说的标准类型的示例。虽然本书的讨论在第 6 章 - 值对象中，但他建议标准类型应该是其本机 BC中的实体，我们应该尝试将它们视为消费 BC中的 VO ：

我们可以将这些视为实体，因为它们在专用的本地限界上下文中拥有自己的生命。不管它们是如何由任何类型的标准机构创建和维护的，如果可能的话，我们应该努力将它们视为我们消费上下文中的值。[...]

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

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

于 2019-02-20T00:07:08.563 回答