Decoupling request and action?

[jackwilsdon]

Should request and action be decoupled, so that an action can be fired off from anywhere (e.g. CLI or web)?

The way I imagine it working would be that some form of DTO would be passed into the action, only specifying the data which is required, which would be generated by the caller.

Could I be misunderstanding the way ADR should be used, and instead the action should be the code which generates the DTO before calling a domain service and associated responder? Where should any non-domain stuff go such as request validation?

[pmjones]

This is a great question.

The Action and Responder are specifically part of the "web" user interface (i.e., the HTTP request and response). It is the Domain that should be able to be "fired off from anywhere." That is, the Domain is the true/core/real thing being invoked, and the Action (or the CLI command) is only a user-interface to it. That means the the Action (or CLI command) should only put together and pass along enough input for the Domain element to do its work. In ADR, the Action then takes the Domain result and passes it to the Responder, but a CLI command might do something else with the Domain result.

Where should any non-domain stuff go such as request validation?

That depends on what you mean by "request validation." If you mean "validating that the inputs to the Domain element are correct" then that probably belongs in the Domain element.

Does that begin to help?

[jackwilsdon]

It certainly does! It seems that I misunderstood actions, as I was almost treating them as part of the domain.

In regards to "request validation", an example would be handling failed deserialisation of a JSON string (i.e. completely invalid JSON). After your explanation of actions, it sounds like that belongs in an action and is related to the short-circuiting of the domain logic as explained in the documentation?

Thanks for the reply, it's been a great help!