Orm 绕过聚合根以编辑单个模型

这是另一个问题的后续问题：

这个问题的作者问，在他的例子中，绕过聚合根是否可以接受。我有同样的问题，但针对不同的用例

我们的web应用程序有一个后台办公室，我们可以在其中编辑属于聚合根目录的所有项目：

• 产品（聚合根）
• 选择权
• 选项项目

等等

由于产品不是在一个批次中创建的，因此我们在单独的屏幕中逐个编辑聚合根中的每个实体。 由于我们处在一个无状态系统中，我们需要在URL参数中唯一地标识我们想要处理的实体。 这意味着，例如，我们将根据选项的

id

获取和编辑选项，而不是从根目录进行浏览

IMHO，为每一个存储库都设置一个存储库更有意义，只需执行以下操作：

$optionRepository->find($optionId);

而不是像：

foreach ($product->options as $option) {
    if ($option->id == $optionId) {
        // ok, we finally found it, we can now work on it
        // ...
        break;
    }
}

---

这是否打破了领域驱动设计的聚合根概念？在这种情况下，我将非常感谢学习正确的方法。

这打破了聚合根的概念。没有一个“正确”的方法来做这件事。要么决定忽略聚合根规则并直接访问对象，要么决定遵循聚合规则并从根遍历到对象。您可以这样或那样做，实际上没有任何其他可能的方法，因此没有任何第三种方法表示直接访问对象并仍然遵守聚合根规则的“正确”方法

这是一个选择的问题。如果有某种令人信服的理由，我个人会打破聚合根规则。除非清单很大，否则你的建议可能是最方便的。真的那么方便吗？您必须创建和维护另一个存储库等

问题是，一旦您创建了选项库，人们就会使用它。无论何时何地。然后是下一个场景，当然你还有其他类似的情况。让我们创建另一个存储库。我们在那里做的为什么不在这里呢？很快，您就可以为每个对象建立一个存储库，不管怎样，这最终都会发生

不说那是好事还是坏事。我以前在没有正式聚合根的应用程序上工作过。我想说的是，这并不是一种真正的中间立场。如果你打算使用它们，你必须严格遵守聚合根规则——你要么识别聚合根并始终遵循这些规则（除非在极端特殊的情况下，你所描述的情况并非如此），要么干脆不使用它们

---

一致性可能同样重要。我要么观察聚合根，要么完全消除它们可能代表的潜在负担。

如果您不从聚合根加载实体，您将无法强制执行聚合不变量（例如，产品不能有多个A类选项）。因此，您的数据可能不一致。

谢谢，我明白您的意思。您是否建议使用其他方法在仍然从聚合根目录浏览的情况下定位精确的项目？不，您无能为力。您可以编写一些帮助器方法，以便隐藏遍历对象、枚举列表等的实际过程，调用方似乎执行某种简单的get方法，但在第6天结束时，您仍然从根遍历聚合。这是有意义的。在仍然编辑聚合树深处的单个实体的同时，是否还有其他方法来实施这些规则？这里不能有其他方法使用域驱动设计来实现。虽然您可以使用数据库查询强制执行此不变量，但这意味着您已经将业务逻辑移到了域之外。这种方法违反了域驱动的设计，导致了数据驱动的应用程序