我目前正在尝试在我正在处理的项目中应用领域驱动设计，我注意到一些命令是相似的，除了每个命令的业务验证执行方式有一些小的差异。举个例子，假设我有这三个命令：
ShipCar Command
ShipMotorcycle Command
ShipTruck Command
您认为将上述所有命令组合成以下命令并以车辆类型作为参数是否明智？
ShipVehicle(VehicleType) command
我们在命名命令时应该有多明确？我是否通过将类似的命令合二为一来让自己失败？
【问题讨论】：
标签： architecture domain-driven-design cqrs domain-model
这两种方法都可以。您也可以同时拥有这两个概念。拥有派生自类或实现接口ShipVehicleCommand 的具体ShiMotorcycleCommand 可能很有用。这取决于您的域和实施的要求。
因为 DDD 鼓励您在系统的领域中建模，所以您应该使用您和您的领域专家使用的普遍存在的语言推导出你的概念。
如果您的 域 概括这些概念并使用 Vehicle 的概念，而不是使用更具体的概念，例如 Car、Truck 和 摩托车，请使用 ShipVehicle。如果没有，请改用ShipCar、ShipTruck 和ShipMotorcycle。
使用您的域来指导您。
如果在您的实施过程中您确实发现有一个通用概念很有用，那么添加它。如果您认为它不会带来任何价值并使系统混乱，请不要这样做。如果你有一个，但它确实混淆了你的系统，请将其删除。
DDD 鼓励使用带有重构的迭代（敏捷）流程，以便在您发现和了解更多模型时更改模型。从您的域开始，看看它会把你带到哪里。
当我开始使用 DDD 时，我注意到的一件事是，作为一名了解设计模式和架构的开发人员，我从一开始就倾向于进行大量抽象。当我停下来开始更多地思考我领域的具体概念时，建模开始变得容易得多。现在，当我了解更多关于域和系统时，我会进行概括和抽象。
【讨论】：