pmjones/adr-example

An example ADR subsystem.

Action Domain Responder Example

This example shows an Action Domain Responder user interface subsystem, with the corresponding domain logic and data source elements, for a naive blogging system.

This is not a running example, in the sense that it cannot be dropped onto a web server and begin operating properly.

However, there is a full test suite in the tests/ directory. (These are more properly considred integration rather than unit tests, but they will do for the purpose of this example.) Issue composer install followed by ./vendor/bin/phpunit to run the tests.

There is no authentication, authorization, or session mechanism included. While necessary in a real system, they would increase the complexity of the example and make it more difficult to discern the separation of concerns.

Action

The Action classes depend on 3rd-party HTTP Request and Response interfaces.

Each Action picks apart the incoming request to pass individual typehinted Domain method arguments. A differently-constructed Domain might require a different input signature, such as a data transfer object or a catch-all array of all possible request values.

Domain

The base ApplicationService class protects all the "real" service methods behind the magic __call() method. This allows the service to implement some functionality common to all the service methods, such as exception handling, though it does get in the way of IDE auto-completion.

The BlogService methods return a domain Payload that wraps the domain results and includes a status indicator. This standardizes the domain return signature, makes the BlogResponder work much more readable.

The domain logic uses a Data Mapper for data source interactions (BlogMapper et al.).

Responder

Each Responder calls a method corresponding to the domain Payload status to build the HTTP Response.

The base Responder class depends on a 3rd-party HTTP Request interface and Response object.

The base BlogResponder class depends on a 3rd-party PHP-based Template View system. The templates are located in resources/templates/blog/.

adr-example's Issues

Using ADR, where would I build a complex page with multiple data and cached items?

I'm trying to build a dashboard for the user (after logging in), in that dashboard the user can see his data, and I also calculate some data and would want to cache that before returning it to the user.

Where would all this logic happen? Following ADR?

Poor domain logic

Hey @pmjones the example it's well structured and easy to understand, but i think this it's not a real domain with real complex logic.
Are you planning to do some real-world and handle some domain complexity?
If help needed ping me 😄

Responding in Various Formats

@pmjones Quick question but I thought I'd ask it here for everyone's benefit.

When responding with the same payload but in more than 1 format (for instance, user may request JSON, CSV, or XML), how would you structure your responder classes?

Some options I'm considering (and caveats):

1. Have abstract JSON, CSV, and XML responders. (Possible inheritance hell)
2. Make each responder handle all possible formats. (Huge responders, likely code repetition)
3. Use traits for serializing payloads to each format. (Only allows for generic serialization, no custom logic per responder)
4. Become a graphic designer. (More free time but even fewer problems with concrete answers)