【问题标题】:DDD When should I create a domain object and a persistence object instead of using a persistence object as a domain object?DDD 什么时候应该创建域对象和持久性对象,而不是使用持久性对象作为域对象?
【发布时间】:2015-10-21 20:47:43
【问题描述】:

随着我对领域驱动设计的理解,我发现我有一个似乎有效的规则,但我想看看它是否有点矫枉过正,也想看看同样情况的其他观点。

我的问题是:“域模型和持久性模型什么时候应该包含在不同的对象中?” 目前我选择的语言是 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 对象交互的存储库接口。这个工厂是域中唯一使用持久存储库的部分,因此也是唯一与持久层交互的部分。

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

我肯定会被纠正。

【问题讨论】:

    标签: java spring jpa domain-driven-design ddd-repositories


    【解决方案1】:

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

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

    我很乐意接受这种混合并为我的域对象添加注释。据我所知,它使持久性更容易管理......但同时,我对 Hibernate/JPA 感到非常满意,并且已经使用了 10 年 :)。

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

    【讨论】:

    • 感谢您的观点。我有点害怕混合领域和持久性,因为我认为其他专业人士不会这样做。我会尝试一下,看看我有多喜欢它。我同意在使用 JPA 的情况下进行分离绝对看起来像是另一层并非绝对必要的复杂性。我喜欢你如何回答更多关于将事情放在一起的问题。我希望看到有人主张将它们分开的答案,这样我就可以看看在使用 JPA 的情况下是否有充分的理由这样做。
    • 这也正是我的立场,感谢 Augusto 把它比我本来的更好:) 另外,我对 Java 不太了解,但没有“侵入式”的替代方案JPA 注释,其中映射细节将被外部化为某种“流畅的映射”文件(如过去的 XML ORM 配置,但在代码中)?这对持久性无知IMO有很大帮助。
    • @guillaume31 Hibernate 仍然支持 XML 映射(很多年前我的同事更喜欢这种方法,因此生产代码和映射之间没有静态关联)。我不知道有任何扩展可能允许在一个不错的 DSL 中定义映射......但这可能是构建一个的问题(不幸的是,它是特定于 ORM 的)。最后...我从未见过在 Java 中数据访问是 100% 透明的应用程序,它总是一个泄漏的抽象。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-07-15
    • 2013-02-19
    • 1970-01-01
    • 2021-04-05
    • 1970-01-01
    • 2013-04-09
    • 1970-01-01
    相关资源
    最近更新 更多