I am on the right path here or is this way off from proper form/practice?

You are on the right path.

The way I have it imagined is that I can send command objects

This spelling isn't quite right -- you aren't sending command objects, you are sending command messages. See At the Boundaries, Applications Are Not Object Oriented.

You'll want to be careful with the vocabulary here; command messages aren't the same thing as the Command pattern described in the Gang of Four book, and neither of those is quite the same as what Grady Booch's Command Query Separation.

The reference you want here is Enterprise Integration Patterns, where Hohpe describes the relationship between command messages and command objects.

After receiving a command in the API, what steps are followed to apply the command to a domain entity, validate against any business rules, and ultimately persist the changes?

You'll normally first validate the message -- which is to say make sure that the message of itself conforms to your specification. You then hand that message off to the domain model to check the message against the current state, and compute appropriate changes.

any domain invariant violations would result in exception being thrown from the domain model and ultimately coming back to client in form of 500 error.

That's probably not quite right -- if the domain model does the right thing by protecting the state from a wrong message, then you should be using a 4xx status-code.

RFC 5789 includes a decent overview of how you might discriminate among the different members of the 4xx class of status-codes.

I am on the right path here or is this way off from proper form/practice?

You are on the right path.

The way I have it imagined is that I can send command objects

This spelling isn't quite right -- you aren't sending command objects, you are sending command messages. See At the Boundaries, Applications Are Not Object Oriented.

You'll want to be careful with the vocabulary here; command messages aren't the same thing as the Command pattern described in the Gang of Four book, and neither of those is quite the same as what Grady Booch's Command Query Separation.

The reference you want here is Enterprise Integration Patterns, where Hohpe describes the relationship between command messages and command objects.

After receiving a command in the API, what steps are followed to apply the command to a domain entity, validate against any business rules, and ultimately persist the changes?

You'll normally first validate the message -- which is to say make sure that the message of itself conforms to your specification. You then hand that message off to the domain model to check the message against the current state, and compute appropriate changes.

any domain invariant violations would result in exception being thrown from the domain model and ultimately coming back to client in form of 500 error.

That's probably not quite right -- if the domain model does the right thing by protecting the state from a wrong message, then you should be using a 4xx status-code.

RFC 5789 includes a decent overview of how you might discriminate among the different members of the 4xx class of status-codes.

I am on the right path here or is this way off from proper form/practice?

You are on the right path.

The way I have it imagined is that I can send command objects

This spelling isn't quite right -- you aren't sending command objects, you are sending command messages. See At the Boundaries, Applications Are Not Object Oriented.

After receiving a command in the API, what steps are followed to apply the command to a domain entity, validate against any business rules, and ultimately persist the changes?

You'll normally first validate the message -- which is to say make sure that the message of itself conforms to your specification. You then hand that message off to the domain model to check the message against the current state, and compute appropriate changes.

any domain invariant violations would result in exception being thrown from the domain model and ultimately coming back to client in form of 500 error.

That's probably not quite right -- if the domain model does the right thing by protecting the state from a wrong message, then you should be using a 4xx status-code.

RFC 5789 includes a decent overview of how you might discriminate among the different members of the 4xx class of status-codes.

I am on the right path here or is this way off from proper form/practice?

You are on the right path.

The way I have it imagined is that I can send command objects

This spelling isn't quite right -- you aren't sending command objects, you are sending command messages. See At the Boundaries, Applications Are Not Object Oriented.

You'll want to be careful with the vocabulary here; command messages aren't the same thing as the Command pattern described in the Gang of Four book, and neither of those is quite the same as what Grady Booch's Command Query Separation.

The reference you want here is Enterprise Integration Patterns, where Hohpe describes the relationship between command messages and command objects.

After receiving a command in the API, what steps are followed to apply the command to a domain entity, validate against any business rules, and ultimately persist the changes?

You'll normally first validate the message -- which is to say make sure that the message of itself conforms to your specification. You then hand that message off to the domain model to check the message against the current state, and compute appropriate changes.

any domain invariant violations would result in exception being thrown from the domain model and ultimately coming back to client in form of 500 error.

That's probably not quite right -- if the domain model does the right thing by protecting the state from a wrong message, then you should be using a 4xx status-code.

RFC 5789 includes a decent overview of how you might discriminate among the different members of the 4xx class of status-codes.