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

Question

我最近在学习 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 是 article 的属性，所以最好留在 article 的域中。

对于聚合根，我正在考虑有一个独立的网页来增删改查类别，包括在类别管理页面中将一篇文章分配给一个类别，而不是在文章详细页面（我们可以在其中更新内容和属性）文章）。似乎将类别建模为值对象将无法实现这一点。

我可以就此获得一些建议吗？谢谢

Answer 1

After reading articles and books, I am very confused what type of domain model that Category should be modelled. Seems like it is reasonable to model it as either value object or aggregate root.

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

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

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

换句话说，这看起来像是数据库的数据模型。这很好——但这并不是 DDD 模式通常适用的那种问题。实体和值的区别 objects，以及聚合在生命周期管理中的使用，当您实际上不管理代码中的任何更改时，就会失去很多力量。

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

Answer 2

您可以用不同的方式表示类别，具体取决于您计划开发以解决特定问题的业务逻辑。

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

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

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

Shall I model article category as value object when design with DDD?

domain-driven-design