如何使用 DDD 和 ORM 正确构建关系 1:M？答案

【问题标题】：How to correctly build a relation 1:M in aggregate using DDD and ORM?如何使用 DDD 和 ORM 正确构建关系 1:M？
【发布时间】：2017-01-18 01:24:19
【问题描述】：

我有两个实体：Rule 和 Violation，1:M。

有两种可能的方式来设计 ORM 中的这种关系：

1:M 双向，当我们在violations 表中有rule_id 外键时
1:m Unidirectional 与 Join Table，当我们有 3 个表时：rules、violations 和 rule_violation。

从我读到的 DDD 理论来看，规则是一个聚合根，我们只能通过它的聚合根 - 规则实体访问 Violation。

问题是上面两个应该使用什么关系以及如何设计实体。

例如，不清楚 Violation 实体中是否应包含 ruleId。

有这样的构造函数是否正确：

class Violation
{
    public function __construct(ViolationId $vid, RuleId $rid, /* other parameters /*)
}

或者就这样

class Violation
{
    public function __construct(ViolationId $vid, /* other parameters /*)
}

如果在 Violation 中有 ruleId 是可以的，那么如何用 ORM（Hibernate 或 Doctrine）映射它。因为 Doctrine 处理关系和对象，而不是简单的整数。

请指教。

【问题讨论】：

【解决方案1】：

经验法则是先设计模型，然后弄清楚如何持久化它。此时，您的持久性框架可能会迫使您对其进行一些调整以使其具有持久性，但您不应该选择一个会迫使您因过多的持久性问题而污染您的模型的持久性框架。

例如，如果 Violation 是 Rule 聚合的一部分，那么从模型的角度来看，Violation 可能不必持有对它的 Rule 的引用，因为所有 Violation 操作都是通过根。但是，根据您在内部对行为建模的方式，您可能还需要双向关联，但此时它不应该与持久性有任何关系。

现在，如果您选择的持久性框架需要Violation 来保存ruleId，那么您可能必须对您的模型进行此调整，并用持久性问题污染您的模型以便实用。但是，请尽量不要让持久性框架驱动您的模型，如果它对您的模型影响太大，那么可能该框架不够灵活，无法提供持久性无知，您应该考虑切换。

【讨论】：