Clean Architecture与DDD中用例的多参与者处理策略

核心原则：别硬拆用例，按职责拆分而非按用户类型拆分 #

单一职责原则（SRP）不是让你把「获取指定文章评论」拆成两个独立用例，而是要把权限校验、数据获取、视图输出这几个职责拆开。毕竟获取评论的核心逻辑（从仓库取数、排序、分页）是完全统一的，差异只在于返回给用户的内容细节（比如匿名用户看不到编辑/点赞按钮，已认证用户能看到自己的操作权限），以及前置的权限过滤（如果有的话）。

具体落地策略 #

1. 写一个核心的获取评论用例 #

创建GetArticleCommentsUseCase，只负责最核心的业务逻辑：

• 接收参数：文章ID、分页信息、当前用户上下文（匿名用户传null即可）
• 从评论仓库拉取该文章的所有基础评论数据（包含点赞数、评论者信息、发布时间等）
• 调用权限服务，判断当前用户对每条评论的操作权限（能不能编辑、有没有点过赞）
• 把原始数据+权限判断结果传给视图组装器

2. 用视图模型分离不同用户的返回结构 #

针对两类用户分别做视图模型：

• AnonymousCommentViewModel：只保留评论内容、发布时间、评论者昵称、总点赞数这些纯展示字段，不带任何操作入口
• AuthenticatedCommentViewModel：在匿名模型基础上，新增canEdit（布尔值）、hasLiked（布尔值）、editActionUri这些和操作相关的字段

然后写一个CommentViewModelAssembler，根据当前用户是否认证，自动选择对应的视图模型组装数据，把用例返回的原始数据转换成适合用户的响应格式。

3. 权限逻辑单独封装，别塞在用例里 #

把权限判断逻辑抽成CommentPermissionService，提供canEditComment(Comment, User)、hasUserLikedComment(Comment, User)这类方法。用例只需要调用这些方法，不用关心具体规则（比如只有评论作者或管理员能编辑，用户点赞过就返回true）。这样后续改权限规则时，只动这个服务就行，不影响核心用例。

4. 控制器层负责传递用户上下文 #

API控制器里先解析当前请求的用户身份（是匿名还是已认证的用户对象），然后把这个上下文传给核心用例。控制器只做请求接收、调用用例、返回响应这几件事，符合Clean Architecture的边界要求。

为什么不拆成两个用例？ #

• 拆了会重复造轮子：两个用例都要写获取评论、分页、排序的逻辑，违反DRY原则
• 核心逻辑分散：以后要改评论排序规则，得同时改两个用例，维护成本翻倍
• SRP的本质是「一个类只对应一个变化原因」，获取评论的变化原因是评论的存储规则、排序规则，而用户权限是另一个变化原因，应该通过拆分服务和视图来处理，不是拆分用例

特殊情况：如果权限涉及数据过滤 #

要是匿名用户只能看公开评论，已认证用户能看自己的私密评论或未审核评论，这种情况也不用拆用例：

• 让核心用例根据用户上下文，调用仓库的不同方法（比如getPublicComments(articleId)和getAllCommentsForUser(articleId, userId)）
• 或者在仓库层统一处理，接收用户参数，自动返回符合权限的数据

内容的提问来源于stack exchange，提问作者Dany Nuñez