java - DDD 什么时候应该创建域对象和持久化对象而不是将持久化对象用作域对象？

Question

随着我对领域驱动设计的理解，我发现我有一个似乎有效的规则，尽管我想看看它是否过分杀伤力，也想看看相同情况的其他观点。

我的问题是:“域模型和持久性模型什么时候应该包含在单独的对象中？” 我目前选择的语言是 Java，我正在使用 Spring Data 的存储库模型。

我看到了我的问题的三个主要答案。

1. 始终使用与持久性对象不同的域对象。
2. 仅当将域方法(行为)放在持久性对象上不切实际时，才使用单独的域对象。
3. 在所有情况下都将持久性对象用作域对象。

为了提出有关 DDD 的问题，我发现我必须使用示例限界上下文，因为我对 DDD 的了解还不够多，无法以更抽象的方式提出问题。

这是我的说明性限界上下文:假设我有一个具有以下业务规则的法律编纂系统:

1. 必须对书籍中的每条法律进行分类。
2. 每条法律都有一个标识符，由两部分组成，编码编号前缀和编码共同分配后缀。 (例如:100-0100、599-2030)。
3. 有多个司法管辖区正在使用法律编纂系统，它们应该能够进行自己的共同分配，但编纂前缀是全局性的，所有司法管辖区必须相同，以促进一般可比性。
4. 编纂编号前缀分为广泛的编纂类别。编码类别有一个数字范围，例如100-199、200-299、700-799等。

为了将此限界上下文表达为持久性模型，我有以下内容:

table: codification
fields: chart_code, prefix, coassign, codification_category

table: codification_chart
fields: chart_code, jurisdiction_description

table: codification_category
fields: category, low_category_number, high_category_number, description

table: global_codification
fields: prefix, coassign, codification_category

我知道，我应该首先从领域模型开始。我有一个持久化模型和一个域模型

在我的领域模型中，我有三个领域对象

public Codification {
    private String prefix, coassign;
    codificationCategory codificationCaegory; // an enum type
    public Codification(...) { // set private vars }
    // getters for private variables
}

public CodificationChart {
    private List<Codification> chartCodifications = new ArrayList<>();
    private String chartCode;
    // public constructor to initialize private variables
    // getters for private variables
    public Codification addCodificationToChart(Codification){...}
    public void removeCodificationFromChart(Codification){...}
    public boolean checkCodificationInChart(Codification){...}
}

public enum CodificationCategory {
    CIVIL, CRIMINAL, PROPERTY, CORPORATE, FAMILY, CONSUMER, ETHICS, BANKRUPTCY;
}

ORM 对象:

JPA Mappings of the tables mentioned earlier with the "Entity" suffix added to their table names. 
They are omitted for brevity. 
Each one contains getters and setters like JPA Pojos do. 
If someone asks for the Persistence objects code I will post it.

我的域对象知道持久性模型的唯一点是在我的工厂对象 CodificationChartFactory 中，它具有我用来与前面提到的 ORM 对象交互的存储库接口(interface)。该工厂是域中唯一使用持久性存储库的部分，因此也是唯一与持久层交互的部分。

在这里创建一个单独的领域模型是在浪费精力吗？ 我可以看到如何将我的 CodificationChart 行为放在 Persistence 对象上。将这些行为放在唯一的工作就是从数据库中检索记录的持久性对象上感觉有点不对。

我绝对愿意接受纠正。

Answer 1

这两种方法都是正确的，并且从设计的角度来看是一种品味问题。有些人不希望他们的域对象与持久性有任何关系，而是创建一个额外的 Entity 对象层......有些人认为这不是主要问题并且很高兴继续使用域对象作为持久性对象。

就我个人(和主观)而言，我认为使用 JPA 并拥有一个额外的 Entity 对象层是错误的方法。像 Hibernate 这样的 ORM 的目标是成为对象和关系模型之间的桥梁(我知道它的名字:)。我认为一种更好的方法是使用 mybatis 或纯 SQL 之类的方法，但绝对不是 JPA...否则它只是为了增加复杂性复杂性(JPA 不是最容易学习的框架)

我很乐意混合使用并注释我的域对象。据我所知，它使持久性更易于管理……但与此同时，我对 Hibernate/JPA 感到非常满意并且已经使用了 10 年:)。

3 年前我有一个非常相似的问题，我将其发布在程序员网站上 - Do ORMs enable the creation of rich domain models?