基于CQRS+MediatR+清洁架构的订单API：复杂命令与返回类型疑问

1. 如何构建包含商品列表的命令？ #

• 命令本质是不可变的业务数据载体，完全可以包含商品列表这类复杂结构，但要避开几个误区：
  • 不要直接把API请求对象整个塞进命令。请求对象可能包含表示层特有的冗余字段（比如UI临时状态、前端校验标识），而命令只需要业务执行必需的最小数据，这样能保证命令的纯净性，避免表示层的变化影响应用层。
  • 商品列表可以用应用层内部的嵌套类/专用DTO承载，比如在CreateOrderCommand里定义OrderItem嵌套类，只保留商品ID、购买数量、单价这些业务必需字段；也可以单独定义CreateOrderItemCommandDto（属于应用层，和表示层DTO完全隔离）。
  • 最佳实践：命令只保留业务操作的核心数据，同时在命令级别做基础校验（比如数量不能为负、商品ID非空），可以用FluentValidation这类库和MediatR结合，提前拦截无效请求，避免脏数据流入领域层。

2. 查询Handler的返回类型问题 #

清洁架构的核心是依赖倒置，解决这个问题的关键是在应用层定义独立的返回模型，而非直接返回领域实体或表示层DTO：

• 应用层为查询场景专门定义响应模型，比如OrderDetailQueryResponse，包含API需要返回的所有字段（订单ID、收货人、商品列表、总金额等）。Handler从领域实体映射得到这个模型后返回给表示层。
• 表示层（API层）依赖应用层的响应模型，再根据需求转换成自己的API响应DTO（比如调整字段名、格式化日期金额）。这样表示层只依赖应用层，不直接依赖领域层，完全符合清洁架构的依赖规则。
• 绝对不要把领域实体直接返回给表示层：领域实体包含业务逻辑和内部状态，暴露给表示层会导致领域层的变化直接影响API响应，破坏各层隔离性，还可能泄露内部业务细节。

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