需被多命令/查询处理器调用的实体操作逻辑应置于何处？

优先选择方案1：创建独立的领域服务文件 #

这个逻辑的核心是批量确保实体存在（查找已有/创建缺失），属于领域内的通用操作，完全适合封装成独立的领域服务：

• 符合单一职责原则：各个命令/查询处理器只需专注自身核心业务，通用的实体保障逻辑由专门服务统一负责。
• 复用性与可维护性强：所有调用方共享同一逻辑，后续修改规则（比如调整实体创建约束、优化查询逻辑）时，只需改动这一处，避免在多个处理器中重复修改。
• 实现清晰：服务依赖实体仓储（Repository）完成数据库交互，对外暴露明确的方法（例如ensureEntitiesExist(ids: string[]): Entity[]），调用方无需关心内部查找、创建的细节。

方案2属于反模式，不推荐 #

命令处理器的职责是作为特定业务命令的入口，而非可被复用的工具组件：

• 打破单一职责：让其他处理器调用该命令处理器，会将其从"处理特定命令"的角色扭曲为"通用逻辑提供者"，导致依赖关系混乱。若该命令的业务规则后续变更，会牵连所有调用它的处理器，引发不可预期的问题。
• 隐藏风险：命令处理器通常包含事务管理、事件发布等逻辑，被其他处理器调用时，容易出现事务嵌套、事件重复触发等问题，大幅增加系统复杂度与调试难度。

额外建议 #

如果该逻辑涉及领域规则（比如创建实体时需满足特定业务约束），务必将这些规则封装在领域服务内部，而非分散到各个调用方，确保领域规则的全局一致性。

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