Question

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

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

课程包括类别，日期时间，描述和位置
可以从Dropdownbox中选择类别和位置
特殊设置部分为用户提供了添加的可能性更改类别和位置

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

我真的很困惑。有人可以帮我清楚一下吗？

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）在他的书Implementing Domain-Driven Design中所说的标准类型的示例。尽管本书中的讨论在第6章-值对象中，但他建议标准类型应为本地BC 中的实体，我们应该尝试在中将它们视为VO。消耗BC ：

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

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

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

DDD查找作为实体或值对象

3 个答案: