AggregateRoot不应该是数据库实体吗？

Question

TLDR:使用DB对象作为我的AggregateRoot是否会导致God对象臃肿。与我在使用单独的DbObjects和DDD对象时看到的问题相比。

我正试图通过MediatR处理程序将我对DDD和Clean的理解结合在一起。当我分别读到它们的时候，所有这些都是有意义的，然后我试着把它们放在一起--看起来应该很好，但是其中一个提出了关于另一个的新问题。

DDD聚合根和持久性就是其中之一(在我的例子中是EFCore)。我可以考虑如何从EFCore和典型的CRUD设置中解决这个问题。我也开始明白我是如何做DDD的。但当我试图把它们组合在一起时，它似乎是混乱的或相互冲突的。

如果我有一个有名字的纪念堂。我可以从DDD的角度来处理它，通过一个纪念，以及一个在上面“RecordName”的方法，检查它不是一个已经添加的名称，等等，业务规则。

那么，在我的手推车里，我是否应该：

1. 从DB/上下文中获取纪念对象
2. 将其映射到聚合
3. 记录名字
4. 将其映射回数据库纪念对象，并在记录的名称集合上添加一个新项。
5. 保存到DB/上下文

这感觉更符合我所理解的DDD，但从持久化的角度来看却很混乱。此外，我还有DbObjects，它仍然可以通过直接访问而被违反。

或者，我可以创建一个纪念聚合和根作为我的DB对象。这将消除映射的额外复杂性和某些人仍然直接使用DB对象的可能性。但据我所读到，这将开始导致膨胀的上帝物体，这本身就开始成为一个真正的问题。

这里推荐的路线是什么？

Answer 1

不是的。域对象不是数据库记录，因此不应该将它们映射到数据库。

DDD是关于建模您的领域行为和知识。奥姆斯是关于技术的。这两个人不是在同一个场地上玩的。现在，有很多资源(不幸地是在线资源)将这两种资源混合在一起，在这些资源中，域对象直接使用一些ORM内容进行注释。您可以安全地忽略这些示例。

CQRS也是如此。CQRS也是(通常，虽然不总是)在技术层面，而不是在领域层面。我的一位同事这样说:需求是否分别提及命令和查询？如果不是的话，它就不在领域了。

而且，除非你有充分的理由这样做，否则把这些事情结合在一起是没有意义的。这些理由应该已经告诉你，你希望这些事情是如何结合在一起的，因为你想要完成一些事情。如果你不知道你想用其中的每一个完成什么，那就不要去做！

例如，如果您希望经常或甚至动态地切换技术，则可以使用清洁建筑。您必须支持多个前端或数据库，等等。如果不支持，就没有充分的理由使用它。