命令类设计最佳实践：应为每个命令单独创建类还是采用继承实现？

这是领域驱动设计（DDD）里命令模式实践中非常常见的疑问，我来结合实际项目经验拆解下两种方案的利弊，以及推荐的最佳实践：

优先选择：为每个命令创建独立类 #

虽然看起来会有重复属性，但这种方案在长期维护和语义清晰性上优势巨大：

• 职责单一，语义明确：每个命令类都精准对应一个业务操作——CreateCarCommand就是用来发起创建车辆的请求，UpdateCarCommand就是用来更新已有车辆，看类名就完全清楚意图，不会有继承带来的模糊性。
• 避免冗余属性：比如创建车辆时根本不需要Id（通常是创建后生成），如果用继承，父类大概率会包含Id，导致CreateCarCommand出现一个无意义的属性，容易引发误解甚至错误（比如开发时不小心给创建命令传了Id）。
• 扩展灵活：后续如果要给某个命令加专属属性（比如给CreateCarCommand加IsInitialStock标记，给UpdateCarCommand加LastUpdatedBy操作人信息），完全不会影响另一个命令，各自迭代互不干扰。

示例代码：

public class CreateCarCommand
{
    public string Make { get; set; }
    public string Model { get; set; }
    public int Year { get; set; }
    // 仅创建操作需要的属性，比如是否为初始库存
    public bool IsInitialStock { get; set; }
}

public class UpdateCarCommand
{
    // 更新必须的车辆标识
    public Guid CarId { get; set; }
    public string Make { get; set; }
    public string Model { get; set; }
    public int Year { get; set; }
    // 仅更新操作需要的属性，比如操作人
    public string LastUpdatedBy { get; set; }
}

为什么不推荐继承方案？ #

继承看起来能减少重复代码，但实际上是一种“伪复用”，会带来很多维护隐患：

• 违背"is-a"原则：从业务语义上讲，UpdateCarCommand并不是一种CreateCarCommand，也不是一种泛化的CarCommand——它们是两个完全独立的业务操作，继承关系在这里没有业务逻辑支撑，属于滥用继承。
• 父类变更风险：如果后续给父类CarCommand添加一个属性，所有子类都会自动继承，可能不符合某个命令的业务需求（比如给父类加了LastUpdatedAt，但创建命令根本不需要这个字段）。
• 属性冗余与误解：父类会被迫包含所有子类的公共属性，导致某些命令类出现不需要的属性，增加理解成本，甚至可能引发错误（比如创建命令里的CarId被错误赋值）。

折中方案：复用共享属性而非继承 #

如果实在觉得重复属性不舒服，可以提取共享的属性到一个独立的DTO或记录类型中，在命令类里引用它，这样既实现了复用，又保持了命令类的独立性：

// 共享的车辆基础信息
public record CarBasicInfo(string Make, string Model, int Year);

public class CreateCarCommand
{
    public CarBasicInfo BasicInfo { get; set; }
    public bool IsInitialStock { get; set; }
}

public class UpdateCarCommand
{
    public Guid CarId { get; set; }
    public CarBasicInfo BasicInfo { get; set; }
    public string LastUpdatedBy { get; set; }
}

这种方式既避免了重复代码，又保留了每个命令类的语义清晰和职责单一，是更稳妥的选择。

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