Extract responsibility of parsing command arguments from handlers into commands themselves

[sJhonny-e]

Firstly, I really really like this project; I wish the code I work with every day was half as clean as this.

A small design suggestion - currently, the responsibility of parsing the primitive values of arguments is within the handler classes:

meeting.ChangeMainAttributes(request.Title,
                MeetingTerm.CreateNewBetweenDates(request.TermStartDate, request.TermStartDate), 
                request.Description,
                MeetingLocation.CreateNew(request.MeetingLocationName, request.MeetingLocationAddress, request.MeetingLocationPostalCode, request.MeetingLocationCity),
                MeetingLimits.Create(request.AttendeesLimit, request.GuestsLimit), 

The handler is responsible, in addition to orchestrating the business logic to handle a command / query, for transforming raw values from the command into domain values. e.g. two dates into Terms, location data into MeetingLocation etc.

Would it make sense to move this responsibility to the command objects themselves?
I've started looking into what that would look like on this branch.

Pros

1. Better SRP - handlers just handle logic
2. Better ability to re-use command objects across multiple handlers without repeating parsing code

Cons

1. Commands are no longer easily serializable

[kgrzybek]

Thanks @sJhonny-e for the question!

Interesting, but I see several issues related to this.

First of all, I treat the command as a simple data structure, in your approach the constructor takes the responsibility of a more advanced process of creation. Constructor (in my opinion) should be very, very simple.

The second issue, the most important, is the validation of such a command - in your approach when during the creation of value objects a business error for a single VO can be thrown. It means the client will always get the first exception. Structure validation should be "aggregate validation" (i.e. collect all errors instead of throwing the first one). This is the reason why to perform structure validation FluentValidation is used - it aggregates all data structure rules validation errors.

The third issue is the one you have indicated - serialization will be more difficult, which will affect e.g. logging of commands.

For me constructing Entities/ValueObjects in CommandHandler is normal behavior and responsibility of Application Layer.

[sJhonny-e]

thanks for your reply!
I can see your point. But maybe just playing devil's advocate here, I can also see a couple of drawbacks with the current approach:

1. if there's more than one handler for a particular command, the parsing logic would have to be duplicated in each handler
   1. this may indicate that the parsing logic should reside elsewhere
2. (this might just be a matter of opinion) It may be considered "non-OO" practice to separate the data from the code that validates it. e.g. if we need to change the data of a command, then changes would have to happen in two places (the command object and the validation of it).
   I'll have to dig a bit deeper into how validation is done in this project to understand more.

It seems to me that the concerns you raised above may be solved by:

1. implementing a factory method
2. moving validation logic into the command itself (again, not sure what that would look like), probably into said factory method
3. I can see a couple of options -
   1. having each VO implement an ISerializable interface (not sure I like this, as VOs are part of the core domain. This may be seen as a case of the stripper pattern
   2. implementing serializer classes for each VO / command. Not sure if that's an overkill though.

[kgrzybek]

Hi again @sJhonny-e

if there's more than one handler for a particular command, the parsing logic would have to be duplicated in each handler

The semantic of Command/Request-Response is that you have exactly one receiver of that Command - it means you will have only one Command Handling chain. Unlike an event where you have many recipients. The scenario when you have to create domain objects in several handlers in the same chain is very rare from my experience.

(this might just be a matter of opinion) It may be considered "non-OO" practice to separate the data from the code that validates it. e.g. if we need to change the data of a command, then changes would have to happen in two places (the command object and the validation of it).
I'll have to dig a bit deeper into how validation is done in this project to understand more.

Validation is the one example, logging is the second. How would you log the whole Command object if you are not able to create it?

I treat Commands as data structures so your suggestion about the Factory Method sounds better for me. However, for me, this implementation would be strange, it involves, in my opinion, more work and does not give more value. In my understanding CommandHandler is responsible for the orchestration and creating new objects is part of it.