Introduction

Some time ago, Mr. Paul M. Jones proposed an Action Domain Responder (ADR) pattern, which is an alternative to the Model View Controller (MVC) interface pattern. ADR pattern is better suited for the server-side applications operating with the request/response concept.

ADR pattern is described here.

ADR

ADR introduces objects/responsibilities that correspond to the ones from MVC. However, directions of communication are a bit different.

ADR defines three components:

• action (you can think of it as a controller, or a request handler),
• domain (business logic),
• responder (element that is responsible for building a response).

The domain part is related to the business logic and it is only developer's responsibility how to model and use that, if it is either strict DDD approach (repositories, use cases and everything) or typical Laravel models, or some service layer or something else.

An action is responsible for calling the domain and then passing eventual domain processing result to the responder. So, basically, actions are one-method (thin) controllers, thus we can call it request handlers. Since they are thin controllers, it is quite handy to use them as invokable classes, which also simplifies testing.

A responder in ADR is the presentation layer. The responder receives necessary data form the action and builds the response that is send back to the client. It is also possible, and sometimes handy, to include content negotiation within responder, i.e. prepare the response in the format that suits the client best, based on the request's Accept header.