领域实体设计答案

【问题标题】：Domain entities design领域实体设计
【发布时间】：2025-12-22 20:45:11
【问题描述】：

哪种方法更好更正确。

class Project
int Id
string Name
int CategoryId

或

class Project
int Id,
string Name
Category CategoryId

【问题讨论】：

你的第二个例子最后应该读Category Category吗？ Category 对象是 Category 类的实例还是表示类别 id 的值对象？
它应该是 Category.CategoryID。在我发布的示例中，它是类别类而不是值对象。 CategoryID 是 Project 表中的外键。
在这种情况下，它完全取决于您的域。如果您将Categories 作为Project 聚合根的一部分，那么您必须接受该决定附带的所有规则（此处列出的规则太多了）。主要是您不能直接或在Project 之外创建或修改Category。您必须通过 Project 聚合根上的方法修改 Category。尽管我不知道您的域，但我想您会想在其他地方编辑/创建Categories。如果是这种情况，那么示例 1 更正确（对于 DDD）。
目前我使用映射 1:1 存储过程和域对象。这种方法好吗？将来我想将存储库模式与经典 ADO.NET 一起使用。
持久性细节通常不在 DDD 范围内。理想情况下，在练习 DDD 时，您希望设计一个以应用程序/领域为中心的模型来对您的领域进行建模。因此，任何东西都不应该从您选择的持久层向上爬到您的域模型中。所以换句话说，持久性可以以任何你喜欢的方式完成。

【解决方案1】：

恕我直言，域类，而且不仅所有类都应该以单数形式声明，因为它们代表一种类型。

【讨论】：

从逻辑上讲，应该在相关的实体中使用实体类型（一对一、一对多等），如果您使用 JPA，通常 Project 有一个或多个类别，而不是 CategoryID。跨度>
不，我使用原生 Ado.Net 和 DataReader 对象

【解决方案2】：

项目，而不是项目，因为每个实例将代表一个项目。

【讨论】：

对不起，都代表单个项目。重点是类别属性。
这在一定程度上取决于实现（即您使用的是 Hibernate 还是其他有自己风格的 ORM？）。您可能不想将 ID 称为“类别”，除非某些 ORM 魔术使它引人注目。 ID 是 ID，而不是事物。
我使用原生 ADO.NET 和 DataReader 对象。到目前为止，我们将存储过程与域对象 1:1 映射。我想优化域模型。在数据库中，我们有项目表和类别码本。项目只能有一个类别
如果从数据库中检索项目时，类别对象是完全构造的（而不仅仅是一个整数），那么您可能希望将其称为类别。否则为类别 ID。