Passing CQRS commands directly to Domain objects

Question

~TLDR: I\'m implementing a CQRS + DDD solution for one of my larger projects, and, I\'m wondering if there is any real reason that my command handlers can\'t directly dispatch t

Answer 1

Command objects are usually expressed in primitive types while aggregate method signatures will be expressed in domain concepts.

The fact that you didn't immediately recognized that probably means that you missed a lot of opportunities to make implicit concepts explicit in your domain.

"a registration command that takes in 8+ fields (firstname, lastname, preferred name, dob, title, username, password, department etc)"

What should strike you is that firstname and lastname could definitely form a meaningful whole, such as new FullName(firstname, lastname) and I'm sure there's a lot of other cases where Value Objects (VO) could or should be used in your domain... Username, Password, etc. ? Using VOs to model things that changes together will better describe your model as well as reduce the number of arguments you have to pass around.

Therefore, that makes command objects poor candidates as aggregate method arguments. If you go down that road, you will definitely miss modeling opportunities.

Answer 2

Agree with @plalx.

Take commands as aggregate method arguments may lead to having too many mapping codes inside aggregates: Mapping primitive types to domain objects, which is better to be placed out of the domain objects.

But for simpler projects, I think it is good starter.

In registration case, the bounded context is usually a supporting domain and the complexity usually comes from external integration(email notification, register with social accounts, etc). In this case, I think bounded context integration is more important than the models inside. So take commands as aggregate method arguments may be a quick start to get things done and saves your time to focus on your core domain.