业务层（用例、服务）关注点分离：用户创建时帖子逻辑复用选型咨询

背景 #

最初需求是实现POST /posts接口创建帖子，于是创建了面向业务场景的PostsUsecases类，其中实现了createPost方法。
新需求是实现POST /users接口创建用户，要求创建用户时自动生成默认帖子，为此创建了UsersUsecases类和createUser方法，现在纠结两种实现方案：

1. 在UsersUsecases.createUser中直接复用PostsUsecases.createPost方法
2. 抽离独立的PostService类（不确定归属基础设施层还是业务层），实现核心的createPost逻辑，让PostsUsecases和UsersUsecases都依赖这个类

方案1：直接复用PostsUsecases.createPost #

• 优点：
  • 实现简单，无需额外抽离类，快速满足需求
  • 帖子创建的业务规则（如字段校验、状态设置）统一维护在PostsUsecases中，保持逻辑一致性
• 缺点：
  • 依赖耦合严重：UsersUsecases绑定PostsUsecases，若后续PostsUsecases新增和"用户主动发帖"强相关的逻辑（比如操作日志、权限校验），会不必要地影响用户创建流程
  • 职责边界模糊：PostsUsecases是为"用户主动创建帖子"这个场景设计的，用户创建时生成默认帖子属于附属逻辑，强行复用会让PostsUsecases承担超出其定位的职责

方案2：抽离PostService类 #

先明确类的归属 #

PostService属于业务层，因为它封装的是帖子创建的核心业务规则（比如帖子必须包含标题、默认内容生成规则、数据格式校验等），这些是和业务强绑定的逻辑；基础设施层一般负责数据库操作、第三方接口调用这类通用技术实现，和业务规则无关。

• 优点：
  • 职责清晰：PostService专注于帖子创建的核心逻辑，PostsUsecases处理"用户主动发帖"的场景（参数转换、调用服务、返回响应），UsersUsecases处理"创建用户+生成默认帖"的场景，各模块职责单一
  • 低耦合：两个Usecases类都依赖PostService而非互相依赖，后续修改任一场景逻辑都不会影响另一个，核心业务逻辑的修改只需改动PostService
  • 复用性更强：如果后续新增其他需要创建帖子的场景（比如管理员批量生成帖子），可以直接复用PostService，无需依赖PostsUsecases
• 缺点：
  • 初期需要额外设计类结构，增加少量开发成本，但长期来看能大幅提升代码可维护性

最终建议 #

优先选择方案2，抽离业务层的PostService类：

1. 将帖子创建的核心业务逻辑（字段校验、默认值设置、业务规则校验等）放在PostService中
2. PostsUsecases.createPost负责处理接口请求的参数转换、调用PostService完成创建、返回符合接口规范的响应
3. UsersUsecases.createUser负责处理用户创建的业务逻辑（用户字段校验、保存用户），然后调用PostService为新用户生成默认帖子

这种方式既保证了业务逻辑的复用，又维持了清晰的职责划分，避免不必要的依赖耦合，后续扩展新需求时也更灵活。

内容的提问来源于stack exchange，提问作者eugenedrvnk