I am currently trying to apply domain-driven design on a project I am working on and I noticed that some commands are similar except for a few small differences in the way the business validation is executed for each one. To give you an example lets say I have these three commands:
ShipCar Command
ShipMotorcycle Command
ShipTruck Command
Do you think its wise to combine all of the above commands into the following and have the type of vehicle as a parameter?
ShipVehicle(VehicleType) command
How explicit should we be in naming commands? Am I setting myself up for failure by combining similiar commands into one?
You can do it both ways. You can also do it by having both concepts at the same time. Having concrete ShiMotorcycleCommand that derives from a class or implements an interface ShipVehicleCommand can be usefull. It depends on the requirements on both your domain and your implementation.
Because DDD encourages you to model in the domain of your system, you should use the ubiquitous language that you and your domain experts use to derive your concepts.
If your domain generalizes these concepts and uses the concept of Vehicle more than it uses more specific ones like Car, Truck and Motorcycle, use ShipVehicle. If it doesn't, use ShipCar, ShipTruck and ShipMotorcycle instead.
Use your domain to guide you.
If during your implementation you do find it usefull to have a general concept then add it. If you don't think that it brings any value and muddles the system, don't. If you have one and indeed it muddles you system, remove it.
DDD encourages to use iterative (agile) processes with refactoring to change your model as you discover and learn more about it. Start with your domain and see where it gets you.
When I started with DDD, one of the things that I noticed is that as a developer who has knowlege in design patterns and architectures, I had the tendency to abstract a-lot from the beginning. When I stopped and started thinking more in concrete concepts of my domain, modeling started to be a lot easier. Now I generalize and abstract when I learn more about the domain and the system.