使用 DDD 进行设计时，我应该将文章类别建模为值对象吗？

如何解决使用 DDD 进行设计时，我应该将文章类别建模为值对象吗？

我最近正在学习 DDD，并且正在为文章类别建模而苦苦挣扎。文章管理系统的逻辑如下。

我们有一个可以管理文章的系统。每篇文章可以属于多个类别，一个类别可以有多个文章。

class Category: IValueObject
{
  public string Name { get; set; }
  public string Description { get; set; }
}

class Article: IAggregateRoot
{
  public int Id { get; set; }
  public string Title { get; set; }
  public string Content { get; set; }
  public IEnumerable<Category> Categories { get; set; }
}

阅读文章和书籍后，我很困惑 Category 应该建模什么类型的领域模型。似乎将其建模为值对象或聚合根是合理的。

对于值对象，我觉得 Category 是由 Name 属性标识的。如果两个类别具有相同的名称，则可以肯定地说它们是同一类别。另外，category 是文章的一个属性，所以最好留在文章的领域。

对于聚合根，我正在考虑为 CRUD 类别建立一个独立的网页，包括将文章分配到类别管理页面中的类别，而不是在文章详细信息页面（我们可以在其中更新文章的内容和属性） .似乎将 Category 建模为 value 对象将无法实现这一点。

我可以请教一下吗？谢谢

解决方法

阅读文章和书籍后，我很困惑 Category 应该建模什么类型的领域模型。似乎将其建模为值对象或聚合根是合理的。

这种混乱真的不是你的错。

部分问题在于您的注意力集中在数据上；但从建模的角度来看，我们真正关心的是数据如何随时间变化。

您在此处显示的信息（名称、描述、标题、内容）看起来都像是来自其他地方的信息副本——有人点击了保存按钮，多多！您存储该数据的副本。

换句话说，这看起来像是数据库的数据模型。这很好 - 但这并不是 DDD 模式通常应用于的那种问题。当您实际上没有管理代码中的任何更改时，实体和值对象的区别以及使用聚合进行生命周期管理会失去很多功能。

在文章“聚合”负责其自身变化的领域模型中，如何处理类别的线索将在描述当您获得新信息时文章如何变化的需求中。

,

您可以用不同的方式表示 Category，这取决于您计划开发以解决某些问题的业务逻辑。

例如，您可以有下一个有界上下文：

1. CategoryManagement - 在此上下文中，Category 可以表示为 Aggregate Root - 在这里您将管理 Category 更改，验证 Category 数据的正确性以确保其在 DB 中存储/更新有效，保护文章不变量（例如，确保在某些类别中不能将同一文章添加两次等）
2. ArticleManagement - 在此上下文中，文章将是一个聚合根，此处的类别可以表示为 ValueObject，例如，仅将其显示为编辑器的信息。