阅读这个answer对于授权这样的概念有很大的帮助,但我仍然发现自己在与其他事情挣扎.
为了说明我的困惑,请考虑发表评论的案例.以下是在发布评论之前需要执行的操作.我在括号中指出我认为这个功能应该去哪里.
>确保允许用户角色/状态对此帖子发表评论(授权,转到应用程序)
>确保我们评论的帖子存在并发布(域名)
>确保用户在最后一刻没有发布超过5条评论(限制,直觉说它归于应用程序)
>确保评论不是空字符串(域)
>确保评论没有脏话(域？)
>确保评论在此帖子中没有来自同一用户的重复项(域名？)
>格式化评论(应用程序)
>从注释中删除当前用户不允许的某些HTML标记(应用程序)
>检查垃圾评论(应用程序？)
我无法确定检查垃圾评论是否是域关注或应用程序,同样适用于限制.从我的观点来看,这些问题对我来说都很重要,必须存在.但同样适用于授权,我们知道它不应该在域中.
如果我在域服务和应用程序服务之间拆分这些问题,那么我觉得我的域名没有完全执行,实际上依赖于应用程序进行事先检查.在这种情况下,重点是什么,为什么我不应该在应用程序中全部完成以减少混淆？
我目前的设置是这样的：
控制器 – >
App.CommentingService.Comment() – >
Domain.CommentingService.Comment()
如果有人可以通过所有必需的步骤来创建注释并将其分配到正确的层,从而给出一些推理,那将会很有帮助.
您的设置看起来正确.应用程序服务通常有两种形式：应用程序功能：电子邮件通知,授权,持久性等.除了域之外,您的系统的所有功能都来自此处.
应用程序协调：要满足用例,您需要协调应用程序功能和域.所有的管道都来到这里.
请记住,应用程序协调模型使用案例,因此并不总是匹配1 app service = 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?
相关性隔离,松散耦合,依赖性感染等;所有这些都有很多原因.我将给你一个我最近参与的一个真实的例子：拥有一个松散的组件(它在.NET框架中)只有域服务允许我在Web应用程序,DesktopApp和SOAP Web服务中托管相同的域更改应用程序协调服务,因为每个应用程序的要求和用例都不同.
关于什么进入域和什么不是.很难给你一个直接的答案,因为它取决于你的域名是什么.
即
Make sure user has not posted more than 5 comments in the last minute
你必须质疑你为什么要节流？为了防止凌乱的用户界面？表现原因？防止拒绝服务威胁？或者是在你的“游戏”中违反规则,因为你的“游戏”只是在时间垃圾邮件中向用户提供有限的尝试？这是什么表明什么是域或应用程序.