java - 值对象和实体以及字典类型的 DDD 建模

Question

我想把我的问题带给更多的听众，因为我们已经在公司讨论了一段时间但找不到答案。

假设我们有Transaction 对象，它是聚合根。在 Transaction 中，我们有 Money，它是值对象。

class Transaction {
    private Money money;
    // other stuff
}

和

class Money {
    private BigDecimal amount;
    private String currency;
}

这样的事务可以持久化(我们使用hibernate)以db到简单的表事务

+-----------------+
| transaction     |
+-----------------+
|id : bigint      |
|amount: decimal  |
|currency: varchar|
|other...         |
+-----------------+

一切都会很好但是......客户要求我们在数据库中有货币表(我们称之为字典表)并且每个有钱的表(包括交易)都需要指向货币表:

+-----------------+           +-----------------+
| transaction     |           |curency          |
+-----------------+           +-----------------+
|id : bigint      |     +---> | id: bigint      |
|amount: decimal  |     |     | code: varchar   |
|curr_id: bigint  | ----+     | name: varchar   |
|other...         |           +-----------------+
+-----------------+

所以从现在开始，Money 对象应该如下所示:

class Money {
    private BigDecimal amount;
    private Currency currency;
}

从现在开始我们不能称它为值对象 :( 或者我们可以吗？这也使我们持久化对象的方式变得复杂，因为我们不能再使用 hibernate embedable 因为我们需要编写自己的自定义类型 enter link description here 。对于确定我们不是第一个面临这个问题的人，因为字典类型在使用中很流行，问题是，如何在 DDD 建模的范围内处理它们。

我们在处理地址时也会遇到类似的问题。所以，我们知道我们有像 Country 和 FederalState 这样的字典(它们是分层的)。我们也知道我们应用程序中的许多对象(例如机构)都有自己的地址，但也与 FederalState 有联系。所以在简单的情况下我们会:

class Institution {
    Address address;
    // ...
}

在哪里

class Address {
    String street;
    String houseNo;
    // etc..
    String federalState;
    String country;
}

但我们需要它与联邦州表相关，因此地址将如下所示:

class Address {
    String street;
    String houseNo;
    // etc..
    FederalState federalState;
}

所以我们又遇到了同样的问题，Address从现在开始就不是值对象了。我们知道如何从技术上做到这一点，但从 od ddd 的角度来看，正确的方法是什么？

Answer 1

“从od ddd的角度来看什么是正确的做法”

首先，使用字典实体并没有错。仅仅是因为与字符串值不同，使用与字典实体的关系:

1. 避免拼写错误(更稳健)
2. 允许在不修改代码的情况下管理“值”集 - 您只需从存储中加载字典并填充下拉列表，而不是在代码中定义枚举(更灵活)。

撇开以上两者不谈，业务需求可能会强加这种设计。例如。对于 Currency 情况:当表示为实体时，允许定义 Exchange Rate 关系，它本身可能受制于 'auditable record/history'。存储 ex.rate 随时间变化的方法。
拥有一个 State 字典是(可能的 future )扩展处理不同销售税政策或立法限制(产品/某些州不允许服务 - 请参阅“药用”杂草和其他杂草)。