Model 关于DDD、五层模型和业务逻辑的问题

据我所知，DDD中的模型分为以下几层：

• 存储（数据库、文件、缓存…）
• 映射器（从存储器获取数据）
• 存储库（管理单个实体类型的数据，可以使用不同的映射器）
• 实体（独立于其他层的简单数据容器）
• 服务（处理业务逻辑，如获取按标题字母顺序排列的5篇最新文章，使用存储库）

因此，这是5层（如果我误解了什么，请纠正我）。问题是：

如果我有与单个实体相关的业务逻辑，我应该在实体中还是在服务中实现它

例如，如果我有一篇文章，并且希望检索其所有已批准的评论，那么它应该是

post.getApprovedComments

（实体）还是

CommentsService.getApprovedCommentsForPost（post）

（不，使用

post.getComments（）.filter（comment->comment.approved）

是不对的，因为这会将业务逻辑移出模型。以防万一有人问。）

因此，这是5层（如果我误解了什么，请纠正我）

我认为，就您的代码而言，人们通常会将数据存储、ORM和存储库分组在一个“层”中。另外，不要忘记演讲

如果我有业务逻辑，那就是 与单个实体相关，我应该吗 在实体中或在 服务

是的，如果它是与实体相关的行为，那么它应该驻留在实体中。实体不应该只是简单的数据容器，实体/模型层应该封装与业务模型相关的数据结构和行为。这样，如果你需要在另一个应用程序中重用模型层，你就不必到处寻找你卡在其他层中的相关行为

例如，如果我有一篇文章，并且希望检索其所有已批准的评论，那么>应该是post.getApprovedComments（实体）还是>CommentsService.getApprovedCommentsForPost（帖子）

如果不进一步了解您的体系结构和ORM，很难说。我可能会同意这篇文章。。路由（注释应该是Post实体上的集合），然后getApprovedComments可以是一个简单的linq查询或诸如此类的查询。你建议的基于服务的方法在我看来不太好用

（不，使用post.getComments（）.filter（c->comment.approved）是不对的，因为这会将业务逻辑移出模型。以防万一有人问。）

我不完全同意你的看法。对于这样简单的事情，有些人可能会认为这是可以接受的

我想补充一点：

服务（处理业务逻辑，如获取按标题字母顺序排列的5篇最新文章，使用存储库）

…在我看来，这不是一个很好的服务示例。在本例中，服务层什么也不做——这应该只是PostRepository中定义的查询方法

---

希望这能对你有所帮助……

谢谢你的回答。我得到了一点-与单个实体相关的行为应该在实体中实现。关于您的附录：那么服务的目的是什么？从我所读到的，我不明白存储库的唯一目的是将请求委托给一个具体的映射器。关于第一段（分组）：是的，我知道，我只是剖析我的MVC的m。关于服务层，我只会在必要时添加它。在我看来，简单的获取查询属于存储库，这就是它的用途。我经常发现自己在为一些与业务无关但很复杂的东西编写服务，例如控制器（在MVC的情况下）。例如，构建和发送电子邮件、控制垃圾邮件、审计、与身份验证和授权相关的事情等等。不过，我相信对此有很多不同的看法。