哪一层负责过滤已停用（标记为已删除）的聚合？答案

【问题标题】：What layer has responsibility of filtering deactivated(mark as deleted) aggregate?哪一层负责过滤已停用（标记为已删除）的聚合？
【发布时间】：2021-10-23 11:36:40
【问题描述】：

我阅读了 [this][1] (dont-delete-just-dont) 文章，然后我同意不删除聚合。

我的问题是，如果我不使用 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

【问题讨论】：

标签： microservices domain-driven-design cqrs n-tier-architecture

【解决方案1】：

将“软删除”建模为业务操作的一部分（而不是隐藏它）是一个很好的策略，因此我建议保持这种方式，而不是将其隐藏在持久层中。将查询作为业务关注点的一部分为这些查询添加了正确的上下文，并遵循您可以在 Udi 帖子中阅读的“为任务建模，而不是数据建模”的口头禅。

还有；一般来说;隐藏事情通常会导致代码维护、测试、培训新人等的痛苦。我喜欢遵循的另一个口头禅是“永远知道你在做什么”。

【讨论】：