Este documento presenta el patrón Action-Domain-Responder (ADR) como una alternativa al patrón MVC tradicional para aplicaciones web. ADR separa las responsabilidades en acciones, dominio y respuesta. Las acciones gestionan las peticiones, el dominio contiene la lógica del negocio y el responder genera la respuesta. ADR tiene ventajas como una separación más clara de responsabilidades, clases más pequeñas y testeables, y favorece el uso de patrones de diseño y principios SOLID.

1. SIMPLIFICANDO CONTROLADORES:
Una introducción a Action-Domain-
Responder
Miguel Ángel Sánchez Chordi @slaimer
Valencia, 2 de junio de 2018

2. UN POCO SOBRE MÍ
● PHP Developer desde 2005.
● Miembro de PHP Valencia (anteriormente
SymfonyVLC) desde 2013.
● Senior Backend Developer en Wossom.
Anteriormente en Beroomers.com y Origo.by
● Tengo un blog sobre Clean Code!
○ https://medium.com/all-you-need-is-clean-code
● Podcaster en “Leyendo Ciencia Ficción”!

3. UN POCO SOBRE MÍ
Anteriormente me habrás visto en otras charlas en PHP Valencia como:
● Servicios Web REST (Breve introducción a REST)
○ http://www.slideshare.net/slaimer/introduccin-a-rest-symfonyvlc
○ https://www.youtube.com/watch?v=dWLuTVSMMfs
● ¿Qué es OAuth y cómo se implementa?
○ http://www.slideshare.net/slaimer/qu-es-eso-de-oauth
○ https://www.youtube.com/watch?v=KONIDG1wp4g

4. CONTROLADORES

5. CONTROLADORES
El cajón de sastre de todo proyecto web

6. Patrón MVC - Introducción
● Los controladores son una de las 3 patas del patrón MVC
● MVC fue propuesto en 1979
● Tuvo un gran auge en los 90 y a principios de 2000
● Está pensado para su uso en aplicaciones de interfaz gráfica, donde cada
componente (botón, input, menú…) tiene asociada su triada MVC.

7. Patrón MVC - Introducción
● Los controladores son una de las 3 patas del patrón MVC
● MVC fue propuesto en 1979
● Tuvo un gran auge en los 90 y a principios de 2000
● Está pensado para su uso en aplicaciones de interfaz gráfica, donde cada
componente (botón, input, menú…) tiene asociada su triada MVC.

8. Patrón MVC - Componentes
● El Modelo es el actor principal, el que aglutina la lógica y actualiza el estado.
● La Vista es la parte visual de la aplicación, la representación final de los datos
y de las acciones del usuario.
● La misión del Controlador es ser un canal de comunicación entre la vista y el
modelo.

9. Patrón MVC - Componentes

10. Patrón MVC - Componentes

11. Patrón MVC - Componentes

12. Patrón MVC - Componentes

13. MVC en detalle
● En realidad, no es considerado un patrón arquitectónico, sino un patrón de
interfaz de usuario.
● Si revisamos la literatura disponible en el momento de su concepción,
siempre se hacen referencias a interacciones de usuario, elementos en
pantalla, dispositivos de entrada…
● No se plantea como un patrón global para gobernar toda la aplicación, cada
elemento en pantalla tiene su triada MVC
● Mediante un sistema de mensajería event/subscriber todos los elementos se
mantienen comunicados.

14. MVC en aplicaciones web server-side
● Una aplicación web server-side (monolítica) no sigue este flujo, ya que se
basa en peticiones HTTP.
● A cada petición que se hace se destruye y crea la interfaz gráfica
● No mantienen una interfaz “viva”.

15. SUN Microsystems y MODEL 2
● La primera referencia a MVC y server-side viene de mano de SUN
Microsystems, que se apropió del nombre de sus componentes para su
patrón MODEL 2.
● SUN reinterpretó a su manera cada una de las partes de MVC, y gracias a el
auge de Apache Struts, en el mundillo del desarrollo backend se asimilaron
los componentes MVC tal cual los había planteado MODEL 2

16. SUN Microsystems y Model 2
En 1999 se podía leer en JavaWorld un artículo introductorio de MODEL 2 la
siguiente recomendación:
Properly applied, the Model 2 architecture should result in the concentration of all of the processing logic in the hands
of the controller servlet, with the JSP pages responsible only for the view or presentation.
Esta recomendación cuajó bastante entre los desarrolladores, quedando así para
siempre confundido el concepto y el propósito de controlador MVC.

18. ¿QUÉ ASPECTO TIENE UN CONTROLADOR
A DÍA DE HOY?

19. ¿QUÉ ASPECTO TIENE UN CONTROLADOR
A DÍA DE HOY?
Ejemplos de la Vida Real™

21. Control de “Daños”
● 618 líneas de código
● 30 imports
● 16 métodos
○ 12 públicos
○ 4 private/protected
● 106 líneas de comentarios

22. Control de “Daños”
● 618 líneas de código
● 30 imports
● 16 métodos
○ 12 públicos
○ 4 private/protected
● 106 líneas de comentarios

23. Cuando intentas explicar cómo está organizado el proyecto

25. ...cuando acabas de explicarlo...

27. ...cuando el P.O asigna una tarea a alguien nuevo...

29. ...cuando alguien se cansa y abandona el proyecto.

31. Problemas conocidos
● Contienen lógica de dominio.

32. Problemas conocidos
● Contienen lógica de dominio.
● Difícilmente testeables, y si contienen lógica de dominio, la situación se
agrava (alta probabilidad de código duplicado).

33. Problemas conocidos
● Contienen lógica de dominio.
● Difícilmente testeables, y si contienen lógica de dominio, la situación se
agrava (alta probabilidad de código duplicado).
● Archivos enormes

34. Problemas conocidos
● Contienen lógica de dominio.
● Difícilmente testeables, y si contienen lógica de dominio, la situación se
agrava (alta probabilidad de código duplicado).
● Archivos enormes
● Configuraciones incrustadas (anotaciones)

35. Problemas conocidos
● Contienen lógica de dominio.
● Difícilmente testeables, y si contienen lógica de dominio, la situación se
agrava (alta probabilidad de código duplicado).
● Archivos enormes
● Configuraciones incrustadas (anotaciones)
● Difícil mantenimiento y peor crecimiento del proyecto

36. Problemas conocidos
● Contienen lógica de dominio.
● Difícilmente testeables, y si contienen lógica de dominio, la situación se
agrava (alta probabilidad de código duplicado).
● Archivos enormes
● Configuraciones incrustadas (anotaciones)
● Difícil mantenimiento y peor crecimiento del proyecto
● Curva de aprendizaje para nuevas incorporaciones

37. Problemas conocidos
● Contienen lógica de dominio.
● Difícilmente testeables, y si contienen lógica de dominio, la situación se
agrava (alta probabilidad de código duplicado).
● Archivos enormes
● Configuraciones incrustadas (anotaciones)
● Difícil mantenimiento y peor crecimiento del proyecto
● Curva de aprendizaje para nuevas incorporaciones
● No es SOLID

38. ACTION-DOMAIN-RESPONDER

39. ACTION-DOMAIN-RESPONDER
La alternativa

40. Breve Introducción
Propuesto por Paul M. Jones, ADR nace como una alternativa server-side “real” a
MVC, siendo un patrón pensado para aplicaciones de red en un entorno
Request/Response.
Esto es una ventaja considerable, teniendo en cuenta que la mayoría de
frameworks web actuales implementan este flujo Request/Response

41. Breve Introducción
No es complejo pasar de comprender MVC o MODEL 2 a comprender ADR, las
bases son las misma, pero con pequeñas adaptaciones que hacen que sea más
cómodo de mantener y de modelar nuestro sistema.
Veamos una comparación de los distintos componentes a continuación.

42. Model VS Domain

43. Model VS Domain
● Poca diferencia respecto al Modelo original

44. Model VS Domain
● Poca diferencia respecto al Modelo original
● Responder y Domain no interactúan nunca, a pesar de ello, el Responder
puede usar elementos de dominio como entidades o colecciones con fines de
presentación.

45. Model VS Domain
● Poca diferencia respecto al Modelo original
● Responder y Domain no interactúan nunca, a pesar de ello, el Responder
puede usar elementos de dominio como entidades o colecciones con fines de
presentación.
● El Domain no está concebido como una única clase que gestione la lógica.

46. Model VS Domain
● Poca diferencia respecto al Modelo original
● Responder y Domain no interactúan nunca, a pesar de ello, el Responder
puede usar elementos de dominio como entidades o colecciones con fines de
presentación.
● El Domain no está concebido como una única clase que gestione la lógica.
● La elección de nombre no es casual. Se pretende “forzar” al programador a
pensar en patrones propios de DDD como Application Service o Use Case
para modelar el dominio de la aplicación.

47. Model VS Domain
● Poca diferencia respecto al Modelo original
● Responder y Domain no interactúan nunca, a pesar de ello, el Responder
puede usar elementos de dominio como entidades o colecciones con fines de
presentación.
● El Domain no está concebido como una única clase que gestione la lógica.
● La elección de nombre no es casual. Se pretende “forzar” al programador a
pensar en patrones propios de DDD como Application Service o Use Case
para modelar el dominio de la aplicación.
● Cualquier acción que el sistema pueda ejecutar, pertenece a la capa de
dominio

48. View VS Responder

49. View VS Responder
● En MVC clásico, el controlador es el encargado de generar el cuerpo de la
respuesta (bien serializando el contenido o renderizando una plantilla) y de
inyectarlo en la respuesta, manejando status code, cabeceras, cookies… etc.

50. View VS Responder
● En MVC clásico, el controlador es el encargado de generar el cuerpo de la
respuesta (bien serializando el contenido o renderizando una plantilla) y de
inyectarlo en la respuesta, manejando status code, cabeceras, cookies… etc.
● Para separar por completo lógica de presentación, ADR introduce el
Responder, el componente encargado de gestionar toda la creación de la
respuesta, quitándole dicha responsabilidad al controlador.

51. View VS Responder
● En MVC clásico, el controlador es el encargado de generar el cuerpo de la
respuesta (bien serializando el contenido o renderizando una plantilla) y de
inyectarlo en la respuesta, manejando status code, cabeceras, cookies… etc.
● Para separar por completo lógica de presentación, ADR introduce el
Responder, el componente encargado de gestionar toda la creación de la
respuesta, quitándole dicha responsabilidad al controlador.
● Un mismo responder debe de poder ser utilizado por más de un Action, no
consiste necesariamente en que haya una Responder por cada Action, sino en
que sea el Responder quien manipule la respuesta.

52. Controller VS Action

53. Controller VS Action
● Los controladores “MODEL 2/MVC” suelen tener varios métodos públicos que
corresponden a varias rutas/acciones.

54. Controller VS Action
● Los controladores “MODEL 2/MVC” suelen tener varios métodos públicos que
corresponden a varias rutas/acciones.
● Esto hace que la clase tenga dependencias muy variadas, que el constructor
reciba demasiadas dependencias o que el controlador requiera tener
directamente tener el container de dependencias.

55. Controller VS Action
● Los controladores “MODEL 2/MVC” suelen tener varios métodos públicos que
corresponden a varias rutas/acciones.
● Esto hace que la clase tenga dependencias muy variadas, que el constructor
reciba demasiadas dependencias o que el controlador requiera tener
directamente tener el container de dependencias.
● En ocasiones un mismo controlador hay acciones que devuelven contenido
en HTML y otras en XML/JSON o cualquier otro tipo de serializado.
Provocando que el controlador tenga aún más dependencias.

56. Controller VS Action
● Los actions de ADR en cambio, corresponden cada uno a una única acción.

57. Controller VS Action
● Los actions de ADR en cambio, corresponden cada uno a una única acción.
● Esto ya sucede en microframeworks como Slim, Silex, Hanami, Flask… donde
cada ruta se corresponde directamente con una closure o una clase
individual.

58. Controller VS Action
● Los actions de ADR en cambio, corresponden cada uno a una única acción.
● Esto ya sucede en microframeworks como Slim, Silex, Hanami, Flask… donde
cada ruta se corresponde directamente con una closure o una clase
individual.
● Un action interactúa con el dominio de la misma forma que un controlador
interactúa con el modelo, pero no interactúa con la vista: envía la información
al responder para que este sea el que haga su trabajo

59. Controller VS Action
● Los actions de ADR en cambio, corresponden cada uno a una única acción.
● Esto ya sucede en microframeworks como Slim, Silex, Hanami, Flask… donde
cada ruta se corresponde directamente con una closure o una clase
individual.
● Un action interactúa con el dominio de la misma forma que un controlador
interactúa con el modelo, pero no interactúa con la vista: envía la información
al responder para que este sea el que haga su trabajo
● Más allá de validar la request (método, cabeceras, parámetros, cookies o
autenticación), el resto queda delegado a domain y responder.

60. Ventajas de su uso

61. Ventajas de ADR frente a MVC
● Fuerte separación de responsabilidades

62. Ventajas de ADR frente a MVC
● Fuerte separación de responsabilidades
● Clases muy pequeñas

63. Ventajas de ADR frente a MVC
● Fuerte separación de responsabilidades
● Clases muy pequeñas
● Fácilmente testeable

64. Ventajas de ADR frente a MVC
● Fuerte separación de responsabilidades
● Clases muy pequeñas
● Fácilmente testeable
● Favorece al uso de patrones de comportamiento para modelar el dominio

65. Ventajas de ADR frente a MVC
● Fuerte separación de responsabilidades
● Clases muy pequeñas
● Fácilmente testeable
● Favorece al uso de patrones de comportamiento para modelar el dominio
● Contribuye al naming de clases, simplificando la comprensión del proyecto

66. Ventajas de ADR frente a MVC
● Fuerte separación de responsabilidades
● Clases muy pequeñas
● Fácilmente testeable
● Favorece al uso de patrones de comportamiento para modelar el dominio
● Contribuye al naming de clases, simplificando la comprensión del proyecto

67. Ventajas de ADR frente a MVC
● Fuerte separación de responsabilidades
● Clases muy pequeñas
● Fácilmente testeable
● Favorece al uso de patrones de comportamiento para modelar el dominio
● Contribuye al naming de clases, simplificando la comprensión del proyecto
● El añadir nuevos casos de uso es casi mecánico

68. Ventajas de ADR frente a MVC
● Fuerte separación de responsabilidades
● Clases muy pequeñas
● Fácilmente testeable
● Favorece al uso de patrones de comportamiento para modelar el dominio
● Contribuye al naming de clases, simplificando la comprensión del proyecto
● El añadir nuevos casos de uso es casi mecánico
● Anima a seguir principios SOLID y Clean Code

69. Show me the code!
https://github.com/mangelsnc/adr-blog

70. Preguntas???

71. GRACIAS POR VENIR!