在 RESTish Web 服务中应用 DDD 原则答案

【问题标题】：Applying DDD principles in a RESTish web service在 RESTish Web 服务中应用 DDD 原则
【发布时间】：2013-10-03 06:51:07
【问题描述】：

我正在开发一个 RESTish 网络服务。我想我明白了聚合和组合之间的区别。聚合不会对其引用的对象强制执行生命周期/范围。组合确实对其包含/拥有的对象强制执行生命周期/范围。

如果我删除一个复合对象，那么它包含/拥有的所有对象也会被删除，而删除聚合根不会删除引用的对象。

1) 如果删除聚合根确实不需要删除引用的对象，那么没有引用对象的存储库有什么意义？还是聚合根是指所谓的复合对象？

2) 创建 Web 服务时，您将拥有多个端点，在我的例子中，我有一个实体 Book 和另一个名为 Comment 的实体。如果这本书被删除，将 cmets 留在我的应用程序中是没有意义的。因此，书是一个复合对象。我想我应该不拥有 cmets 存储库，因为这会破坏生命周期的执行以及 book 类可能具有的规则。但是我有 URL，例如（仅示例）：

GET /books/1/comments
POST /books/1/comments

现在，如果我没有 cmets 的存储库，这是否意味着我必须加载 book 对象然后返回引用的 cmets？我是否可以从 BookRepository 返回评论实体列表，这有意义吗？ Book 的存储库最终可能会随着各种方法变得相当大。我是否允许编写针对 cmets 而不是存储库内的书籍的 JPQL（JPA 查询）？ cmets的分页和过滤怎么样。添加 POST 端点触发的新评论时，是否需要加载图书，将评论添加到图书，然后更新整个图书对象？

我目前正在做的是拥有一个自己的 CommentRepository，即使 cmets 随书一起被删除。我可能需要一些关于如何正确执行的指导。由于您不仅要在 RESTish 服务中公开根对象，我想知道如何在后端处理这个问题。

我正在使用 Hibernate 和 Spring。

【问题讨论】：

这个问题似乎是题外话，因为它属于programmers.se。

标签： java spring hibernate spring-mvc domain-driven-design

【解决方案1】：

您的 REST 资源不必与您的 JPA 实体完全匹配。即使您不打算将 cmets 公开为根 REST 资源，有时将其建模为 JPA 实体并为其提供存储库仍然是有意义的。支持这一点的几点：

如果您预计一本书有大量 cmets，请节省通过将其添加到Book.comments 集合来发表评论可能非常效率低下。
当Comment 为一个实体并拥有自己的 ID。
分页实现可能非常如果Comment 是值对象，则效率低。

我会做的是：

两个实体：Book 和 Comment
DB 中的外键可确保当一本书被删除时，所有的 cmets 都会被删除。
每个实体的存储库。 CommentRepository 会有一个方法 findByBook()
/book/{id}/cmets 在 REST 接口中

【讨论】：