Si todo ha ido bien, nuestra Application layer nos dará una respuesta a nuestra petición. Luego el Controller se encargará de mostrar dicha información al User en el formato que necesite.

Especificaciones

No debería ser muy compleja. Sólo debería interpretar la información del Domain hacia algo que el User necesite. Con una complejidad de 1 debería ser suficiente.

Su característica principal es intentamos transmitir que el Domain es una cosa, y lo que el User necesita ver no siempre es lo mismo.

Para perfilarlo mejor, como características más concretas, se alimenta de elementos de Domain como Value objects o Aggregates, decide qué información es relevante para el User, con lo que necesita contener cierta lógica.

Se relaciona con los Controllers, Console commands y los Use case.

• Observaciones: El objeto Response debe pasar los objetos de Domain a primitivos. Sólo debe mostrar lo que el usuario necesita, no toda la entidad.

¿Qué valor me aporta implementar una Response?

• Como Response, establecerá las reglas principales a nivel de valores primitivos y la cantidad de información del Domain que se expone al exterior.
• Habilita la posibilidad de usar construcciones personalizadas usando los objetos de Domain que le pasemos, liberando a las otras capas de esta tarea.

¿Cómo se expresa esta carta en el mundo real?

Como indica el icono de arriba a la izquierda, corresponde a una clase.

Si definimos una Response como si fuera un Presenter, podríamos tener algo parecido a esto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

final readonly class AddFlatResponse
{
    private function __construct(private FlatModel $flat){}

    public static function write(FlatModel $flat): self
    {
        return new AddFlatResponse($flat);
    }

    public function read(): array
    {
        return [
            'id' => $this->flat->id(),
            'description' => $this->flat->description(),
        ];
    }
}

1

TODO: Referencias a otras cartas