Why is the handlers/commands segregated from the domain model?

Apr 12, 2012 at 8:46 AM

Is there an architectural or pattern decision to segregate the domain model from the commands and handlers?

Example: The CreateOrUpdateCatalogCommand has a constructor that takes simple types, CategoryId, name, description and then maps those values to properties on the command itself. Why shouldn't the constructor instead take the domain object, such as a "Catalog" type?

The result is tedious mapping of properties, which is cumbersome and should be avoided if there is not a really good reason for it. If this separation has good reasons, one might consider a mapping framework to handle the mapping from domain model to command and back to domain model again.

Apr 13, 2012 at 9:05 PM
Edited Apr 13, 2012 at 9:06 PM

Because when they are called from a controller in the MVC project the CreateUpdateCatalogCommand would be faster to create using the ViewFormModel properties directly instead of going ViewFormModel -> Catalog -> CreateUpdateCatalogCommnad. No one is stoping you from creating different constructors in the Command type...