Arquitectura Hexagonal - PHPMad -

Charla del 23 de septiembre de 2015. Grupo desarrolladores PHP - PHPMad -

Transcript

1. ARQUITECTURA HEXAGONAL (Ports and Adapters) Adoración González Toboso
2. Algo sobre mí...  Adoración González  Ingeniero en Informática, UCM  PHP Senior Software Developer  @srtaDeveloper  Espartana en mi tiempo libre
3. OBJETIVO “Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.” Alistair Cockburn http://alistair.cockburn.us/Hexagonal+architecture Adoración González Toboso
4. OBJETIVO  Los cambios en un área de una aplicación deberían tener el menor número posible de efectos colaterales.  Agregar nuevas funcionalidades ó formas de interactuar con la aplicación no deberían requerir grandes cambios de código.  Los procesos de depuración y testeo deberían requerir el menor número de soluciones temporales como sea posible y ser relativamente fáciles. Adoración González Toboso
5. DEFINICIÓN  Patrón de arquitectura software.  Versión ampliada del modelo tradicional de arquitectura de 3 capas. Adoración González Toboso
6. PUERTOS Y ADAPTADORES Definimos un protocolo para usar nuestra aplicación.  Identificamos puertos de E/S.  Usamos adaptadores para transformar inputs y outputs.  Organizamos y diseñamos clases para desacoplar. Adoración González Toboso
7. Esquema Adoración González Toboso
8. El hexágono es una representación conceptual mediante la geometría de la figura. El número de lados, no significa nada!! https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html Adoración González Toboso
9. Hexágono de Aplicación  Contiene el modelo de dominio.  Servicios de la aplicación.  Subscribers y listeners de eventos del dominio.  Eventos de la aplicación  Comandos  Bus de comandos. Adoración González Toboso
10. Infraestructura Adoración González Toboso
11. Antes de usar arquitectura hexagonal... Adoración González Toboso
12. Casos de uso Definimos casos de uso ¿Qué tiene que ser capaz de hacer mi aplicación?  Definición de casos de uso pensando en la interfaz del hexágono de la aplicación.  Constituyen una API. Adoración González Toboso
13. Casos de uso: Ejemplo  Registrar una cuenta de usuario.  Habilitar una cuenta de usuario  Deshabilitar una cuenta de usuario.  Modificar el perfil de una cuenta de usuario.  Borrar una cuenta de usuario. Adoración González Toboso
14. Casos de uso: Error Pensar en casos de uso ligados en cómo vamos a interactuar con la aplicación. Adoración González Toboso
15. Caso de uso: Registrar cuenta de usuario
16. Aplicación agnóstica del contexto Los datos para registrar de una cuenta de usuario pueden tener distintos orígenes:  Formulario web (HTTP)  API (HTTP)  CLI  Data provider (Tests)  Message queque Adoración González Toboso
17. Command Adoración González Toboso
18. Command Adoración González Toboso
19. Symfony Controller Adoración González Toboso
20. Symfony Console Command Adoración González Toboso
21. Behat Adoración González Toboso
22. Comandos y Bus de Comandos Adoración González Toboso
23. Command Handler Adoración González Toboso
24. Dominio Adoración González Toboso
25. CodeSmell :( Adoración González Toboso
26. CodeSmell :( Adoración González Toboso
27. S.O.L.I.D  Single responsibility  Open/Closed  Liskov substitution  Interface segregation  Dependency inversion Adoración González Toboso
28. S.O.L.I.D El principio de inversión de dependencias define como es el flujo de dependencias en la aplicación.  Las clases de alto nivel no deberían depender de las clases de bajo nivel. Ambas deberían depender de las abstracciones.  Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones. Adoración González Toboso
29. Dominio Adoración González Toboso
30. UserAccount Adoración González Toboso
31. Mapeo entidad UserAccount Adoración González Toboso
32. UserAccountRegisteredEvent Adoración González Toboso
33. Single Responsability Una clase debería tener sólo una responsabilidad ó una razón para cambiar. Adoración González Toboso
34. Dominio  El modelo de dominio contiene las interfaces del repositorio y la factoría con los métodos que tiene que implementar cualquier clase que ubicada en la infraestructura funcione como un repositorio ó como factoría de cuentas de usuarios independientemente de la tecnología que haya debajo. Adoración González Toboso
35. Dominio  Las implementaciones concretas del repositorio van a ser los adaptadores de la persistencia en la base de datos que tengamos Postgresql, MySql, MongoDB, Redis. Adoración González Toboso
36. Interfaces... nuestras aliadas  Invierten el control, “forzando” a la implementación concreta a cumplir lo definido en el modelo.  Modelo y aplicación desacoplados de la tecnología externa.  Muy mantenible. Adoración González Toboso
37. Infraestructura Adoración González Toboso
38. Adoración González Toboso
39. UserAccountManager Adoración González Toboso
40. Command Bus Adoración González Toboso
41. Command Bus Adoración González Toboso
42. Mailer Adoración González Toboso
43. Mailer Adoración González Toboso
44. Tests “...be developed and tested in isolation from its eventual run-time devices and databases.” Adoración González Toboso
45. Tests Test funcionales ó de ACEPTACIÓN sin BD, ni framework. Adoración González Toboso
46. Tests En lugar de tener una implementación del manager con Doctrine me creo una implementación “in memory”. Adoración González Toboso
47. Tests La implementación en memoria del repositorio me basta para comprobar la validez de la implementación. Adoración González Toboso
48. Aplicación “hexagonalizada” y tests funcionando... Adoración González Toboso
49. Tests funcionando... más test TEST DE INTEGRACIÓN  Comprobar la la configuración del mapeo.  Comprobar la corrección de la implementación concreta del repositorio. TEST DEL SISTEMA  Verificar todo está conectado entre sí. Adoración González Toboso
50. Arquitectura Hexagonal y DDD Adoración González Toboso
51. Ventajas  Diseños SOLIDos, desacoplados y mantenibles.  Aplicaciones agnósticas de contexto.  Identificar fácilmente los detalles de implementación.  Testear es más fácil. Adoración González Toboso
52. Desventajas “¿Aumenta la complejidad del modelo de aplicación?” Adoración González Toboso
53. Referencias  http://alistair.cockburn.us/Hexagonal+architecture Alistair Cockburn  http://fideloper.com Chris Fidao  http://php-and-symfony.matthiasnoback.nl Matthias Noback  http://www.martinfowler.com Martin Fowler  Implementing Domain-Driven Design. Vaughn Vernon.  Domain Driven Design in PHP Carlos Buenosvinos, Christian Soronellas, Keyvan Akbary  PHP Barcelona Monthly Talk: From Silex to Symfony and viceversa. Ronny López  Antonio J. García Lagar @ajgarlag Adoración González Toboso
54. GRACIAS :) Adoración González Toboso
55. Encuéntranos https://twitter.com/phpmad https://www.meetup.com/PHPMad/ https://www.youtube.com/user/phpmadrid