Does logged-in User information belong on a Command?

Question

Imagine I am creating a command called UpdatePhoneNumberCommand. Imagine also that in my application a business rule dictates that no-one may update anyone else's phone number - it is always you updating your own Phone Number.

The number itself obviously needs to go onto the Command as a property (UpdatePhoneNumberCommand.Number), my question is does the UserId belong on there too? You could either a) make it a property on the command, figure out who is logged in and then execute the command or b) leave it off the Command then lookup the currently logged-in User in the CommandHandler (via some abstraction - IUserContext or similar).

I don't like the idea of CommandHandlers being concerned with who is logged-in - even via an abstraction - but I can't really make a convincing case why. It just feels wrong to me - obviously your Handler needs to accept dependencies but I don't feel like figuring out who the subject of a Command is should be looked-up within the Handler.

Do you guys have any advice/heuristics when designing Commands which do something similar?

Answer 1

Do not put figuring out who is currently logged in in command handling, thereofore command should contain user identification (login, db id, whatever).

This is not specific for just one command, so it should be abstracted. And correctly filling it should be handled in one place too.

This way you can test whether finding current user is working separatedly to whether commands are working.

And you can test commands without concept of users being logged in.