我读了[this][1] (not -delete-just-don)文章，然后我同意不删除聚合。
我的问题是，如果我不使用CQRS，哪一层有过滤停用(标记为删除)聚合的责任?它可能是一个用例?
UI层接口是否有过滤器的参数，应用程序层是否在api上显式显示?像这样的吗?
@RequestMapping(value = "/users/{userId}/articles", method = RequestMethod.GET)
public ResponseEntity<String> getArticlesOfUser(
@PathVariable long userId,
@RequestParam(defaultValue = ture, required = false) boolean onlyActivated) {
if(onlyActivated) {
List<Article> articles = articleApplicationService.getAllActivatedArticlesOfUser(userId);
return articlesResponse(articles);
} else {
List<Article> articles = articleApplicationService.getAllArticlesOfUser(userId);
return articlesResponse(articles);
}
}
还是应该隐藏在持久层?像这样的吗?
public class JPAArticleRepository implements ArticleRepository {
...
public List<Article> allArticlesByUserId(long userId) {
boolean activated = false
String query = "select article from Article article
where article.userId = :userId and article.activated= :activated";
...
}
...
}
任何想法吗?
感谢[1]: https://udidahan.com/2009/09/01/dont-delete-just-dont
建模"软删除"作为业务操作的一部分(而不是隐藏它)是一个很好的策略，所以我建议保持这种方式，而不是将其隐藏在持久化层中。将查询作为业务关注点的一部分，可以为这些查询添加正确的上下文，并遵循"为任务建模，而不是为数据建模"的口号。你可以在Udi的帖子中阅读。
也;一般来说;隐藏东西通常会给代码维护、测试、培训新人等带来麻烦。我喜欢遵循的另一个咒语是"永远知道你在做什么"。