{ "href": "/post/2015/05/19/radar-a-psr-7-action-domain-responder-framework/", "relId": "2015/05/19/radar-a-psr-7-action-domain-responder-framework", "title": "Radar: A PSR-7 Action-Domain-Responder Framework", "author": "pmjones", "markup": "html", "tags": [ { "href": "/tag/patterns/", "relId": "patterns", "title": "Patterns", "author": null, "created": null, "updated": [], "markup": "markdown" }, { "href": "/tag/php/", "relId": "php", "title": "PHP", "author": null, "created": null, "updated": [], "markup": "markdown" }, { "href": "/tag/programming/", "relId": "programming", "title": "Programming", "author": null, "created": null, "updated": [], "markup": "markdown" }, { "href": "/tag/radar/", "relId": "radar", "title": "Radar", "author": null, "created": null, "updated": [], "markup": "markdown" } ], "created": "2015-05-19 15:00:58 UTC", "updated": [ "2015-05-19 15:00:58 UTC" ], "html": "

Radar is a PSR-7 compliant Action-Domain-Responder (ADR) system. While it may look like a micro-framework, it is more like a wrapper around the real core of your application domain. Its architecture makes it an excellent complement to Domain Driven Design.

\n
\n

Radar is superficially similar to a micro-framework. It has a routing system to point URLs to actions, a filter-style middleware system to modify the incoming HTTP request and outgoing HTTP response, and a dependency injection container and configuration system to wire everything together.

\n

However, with Radar, you don\u2019t specify \u201ccontrollers\u201d or \u201cclosures\u201d for your routes. Instead, you specify up to three callables per route, all of which are optional:

\n
    \n
  1. \n

    A Domain callable to be invoked with the user input. (If you don\u2019t specify a Domain callable, the Responder will be invoked directly; this is unusual but sometimes convenient.)

    \n
    2. \n
  2. \n

    An Input callable to extract user input from the incoming HTTP ServerRequest. The default Radar Input callable will naively merge the route path attributes (path-info parameters), the query parameters ($_GET), the parsed body parameters ($_POST), and the uploaded files array ($_FILES) into a single associative array of user input.

    \n
    3. \n
  3. \n

    A Responder callable to convert the Domain output to an HTTP response. The default Radar Responder expects a Payload object from the Domain; it delivers JSON output and sets proper HTTP status codes for a wide range of scenarios.

    \n
    4. \n
\n

These three callables are invoked within a standardized ActionHandler. As a result, the Action logic in Radar is always the same for every route. The only variations are in how input is collected, how output is presented, and of course in how your core application domain operates.

\n

So, don\u2019t think of Radar as a micro-framework. Think of it more like a wrapper around the core of your real application domain. Its only purpose is to guide input from the user into the domain, and to present output from the domain back to the user.

\n

You can read the documentation for it here.

\n
\n

Read the Reddit discussion about this post here.

\n" }