domain-driven-design - DDD : What goes into domain and what goes into application?

Question

我发现很难决定某个东西是否应该成为域或应用程序的一部分。

通读 answer授权等概念有很大帮助，但我仍然发现自己在其他事情上苦苦挣扎。

为了说明我的困惑，请考虑一个发表评论的案例。以下是发表评论之前需要做的事情。我在括号中指出我认为这个功能应该去哪里。

确保允许用户角色/状态对此帖子发表评论(授权，转到应用程序)

确保我们正在评论的帖子存在并已发布(域)

确保用户在最后一分钟发表的评论不超过 5 条(节流，直觉说它转到应用程序)

确保评论不是空字符串(域)

确保评论没有脏话(域？)

确保该帖子中的评论没有来自同一用户的重复(域？)

格式化评论(应用程序)

从评论中删除当前用户不允许使用的某些 HTML 标记(应用程序)

检查垃圾邮件的评论(应用程序？)

我无法决定检查垃圾邮件评论是域问题还是应用程序，节流也是如此。从我的角度来看，这两个问题对我来说都很重要，并且必须存在。但是授权也是如此，我们知道它不应该在域中。

如果我在域服务和应用程序服务之间划分这些问题，那么我觉得我的域没有完全强制执行，实际上依赖于应用程序进行事先检查。在那种情况下，重点是什么，为什么我不在应用程序中做这一切以减少困惑？

我当前的设置是这样做的:
Controller ->
App.CommentingService.Comment() ->
Domain.CommentingService.Comment()
如果有人可以完成所有必需的步骤来创建评论并将其分配给正确的层并给出一些推理，那将会很有帮助。

Answer 1

您的设置看起来正确。应用程序服务通常有两种形式:

应用程序功能:电子邮件通知、授权、持久性等。所有功能，除了域，您的系统都在这里。

应用程序协调:要满足用例，您需要协调应用程序功能和域。所有的管道都在这里。

请记住，应用程序协调模型用例并不总是匹配 1 个应用服务 = 1 个域服务，因为用例可能涉及多个进程。

 Controller 
     App.CommentingService.Comment() //coordination of below features and domain
         App.AuthService().Autorize(); //feature
         Domain.CommentingService.Comment(); //domain
         App.PersistenceService().Persist(); //feature
         App.NotificationService().SentNotificationToUser(); //feature

Why don't I just do it all in application to reduce confusion?

职责分离、松耦合、依赖注入(inject)等；所有这些都是好的，原因有很多。我会给你一个我最近参与的真实例子:只有域服务的松散组合(它在 .NET 框架中)允许我在 Web 应用程序、DesktopApp 和 SOAP Web 服务中托管相同的域更改应用程序协调服务，因为每个应用程序的要求和用例都不同。

关于什么进入域，什么没有。很难给你一个直接的答案，因为这很大程度上取决于你的域名是什么。

IE。

Make sure user has not posted more than 5 comments in the last minute

您必须质疑为什么要节流？为了防止困惑的用户界面？性能原因？防止拒绝服务威胁？还是因为您的“游戏”只是在垃圾邮件中向用户提供了有限的尝试，所以在您的“游戏”中违反了规则？这表明什么时候是域或应用程序。