Short-circuiting the domain

[jackwilsdon]

Is it possible to short-circuit the domain and go straight from input to responder? One instance where this would be useful is when a completely invalid input is provided (i.e. invalid JSON) and you don't have anything to pass into the domain.

Looking at how the action handler works, it doesn't look like this is possible at the moment. Is this something worth considering adding?

[pmjones]

One instance where this would be useful is when a completely invalid input is provided (i.e. invalid JSON) and you don't have anything to pass into the domain.

/me furrows brow

I would argue here that anything related to "validation" of inputs should be left to the Domain. That is, the Action should only be collecting input as provided by the user and passing it to the Domain for it to make sense of. (The only exception might be to provide default values when not provided by the user.)

With that in mind, it would make more sense to let the Domain decode the JSON from a string input, and then report back if the JSON decoded improperly. Thus, no need to short-circuit anything at the Action level.

The rule -of-thumb is, if you are doing any conditionals at all in the Action (aside from simple ternaries to provide defaults as noted earlier) then the Action is probably doing too much.

Does that help at all?

[jackwilsdon]

With that in mind, it would make more sense to let the Domain decode the JSON from a string input, and then report back if the JSON decoded improperly. Thus, no need to short-circuit anything at the Action level.

How would I go about implementing support for different request encodings in this case? For example JSON and XML. Would I create two domain classes (e.g. CreateUserJSON and CreateUserXML) for it? Another example would be re-using the domain logic in a command line tool, how can I do that if it's coupled to JSON?

I think I'm not really understanding ADR correctly, as I'm treating actions as more of a controller at the moment.

[pmjones]

Would I create two domain classes (e.g. CreateUserJSON and CreateUserXML) for it?

Could do that; or, you could specify that the user-input is coming in as JSON with an added argument to the domain call. E.g.:

function __invoke($inputString, $format = 'json') {
    if ($format === 'json') { $data = json_decode($inputString); }
    elseif ($format === 'xml') { $data = xml_decode($inputString); }
    else { ... }

    // rest of the domain code
}

Recall also that the Domain portion of ADR is an entry point into the Domain layer, it is not necessarily the only element of your Domain.

I'm treating actions as more of a controller at the moment.

It's a hard habit to break. :-)

[jackwilsdon]

Recall also that the Domain portion of ADR is an entry point into the Domain layer, it is not necessarily the only element of your Domain.

That's a good point - I'll take a look at implementing some "internal" layers in the domain.

It's a hard habit to break. :-)

It certainly is! Have you got any tips? 😛

Thanks for the help, ADR is a bit of a paradigm shift but it seems to be for the better!

[pmjones]

Have you got any tips?

No conditions, loops, or error handling in the Action; drive all decisions to the Domain or the Responder. :-)