Construcción de web aps- un enfoque hexagonal
•Transferir como PPTX, PDF•
0 gostou•235 visualizações
Construcción de aplicaciones web usando un enfoque hexagonal.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (11)
Semelhante a Construcción de web aps- un enfoque hexagonal
Semelhante a Construcción de web aps- un enfoque hexagonal (20)
Último
Último (20)
Construcción de web aps- un enfoque hexagonal
- 2. Arquitectura “Si en una sala llena de diseñadores de software dos de ellos están de acuerdo, eso es una mayoría” Bill Curtis
- 3. Simple application Create Projects :) ...yeah right
- 4. Simple application Create Projects :) ...yeah right
- 7. MVC comes to rescue you … I think
- 8. MVC comes to rescue you Create Project POST /v1/customer/1/project … I think Web endpoint
- 9. MVC comes to rescue you Create Project POST /v1/customer/1/project … I think Web endpoint Controller/ProjectController
- 10. MVC comes to rescue you Create Project POST /v1/customer/1/project … I think Web endpoint Controller/ProjectController Concrete Concrete Concrete Concrete Concrete
- 11. MVC comes to rescue you Create Project POST /v1/customer/1/project … I think Web endpoint Controller/ProjectController Database context Web context Filesystem context
- 12. Domain logic wired to different contexts Web, HTTP Database, ER manager Controller, Request Create Project
- 13. Reuse domain logic in other contexts editRepository() Create project
- 14. Reuse domain logic in other contexts editRepository() Create project How?
- 15. Can I reuse that code?
- 16. Summary of pros/cons Pros - Rapid application development (R.A.D) - Low learning curve - Lots of frameworks in any flavour - Good documentation Cons - Rapid application development (R.A.D) → becomes B.A.D (Bad application development) - Too much coupling between layers - Not good abstraction - Technical debt - Domain logic wired to the framework
- 17. Arquitectura Hexagonal “Hexagonal Architecture is an architecture defined by establishing a perimeter around the domain of your application and establishing adapters for input/output interactions. By establishing this isolation layer, the application becomes unaware of the nature of the things it's interacting with.” Alistair Cockburn
- 18. Heart of hexagonal architecture Inner things Outside things
- 19. Heart of hexagonal architecture Inner things Outside things
- 20. Decoupled application from dependencies Ports (have a language) Adapters (mutate message from port to application). All right, a better explanation Application Port PortPort Port
- 22. Create Project - POST /customer/1/project Create project, a better approach Web endpoint
- 23. Create Project - POST /customer/1/project Create project, a better approach Web endpoint Web endpoint CreateProject CreateProjectFolder CreateProjectEntity
- 24. Alright, show me the code... Adapter mutate message from the web port ProjectController
- 25. Alright, show me the code... Adapter mutate message from the web port ProjectController Good abstraction Context: Create a project
- 26. Alright, show me the code... Adapter mutate message from the web port CreateProjectCommand ProjectController CreateProjectCommand
- 27. Hey, but I want to create a command line script too
- 28. Be solid, ensure the single responsibility principle of your features. Reuse your commands
- 29. Summary of pros/cons Pros - Low technical debt === good architecture - Decoupled layers - A good approach for complex applications with several developers - Good abstraction for the domain logic - Reuse your beautiful code Cons - It’ not too easy to implement as MVC - In some cases the Hexagonal documentation is too abstract
- 30. Preguntas?
Notas do Editor
- Quiero comenzar por la arquitectura, porque? Porqué necesitamos re-inventar la rueda MVC? Tiene algo de malo? Son quizás varias de las preguntas que muchos se hacen en este momento o se hicieron como yo tiempo atrás, y más aún al escuchar este fancy-name the hexagonal architecture. Bueno, tratemos de ver que esta ocurriendo aún en estos días con el desarrollo de web applications.
- Podemos comenzar con una aplicación web simple, algo en lo que todos hemos trabajado alguna vez, y al comienzo es bastante sencillo de crear y mantener, pero esto puede cambiar bastante si otras personas comienzas a trabajar en ella, agregando dependencias, librerías, lógica de negocios etc, haciendo que nuestra simple app, se transforme en esto.
- Podemos comenzar con una aplicación web simple, algo en lo que todos hemos trabajado alguna vez, y al comienzo es bastante sencillo de crear y mantener, pero esto puede cambiar bastante si otras personas comienzas a trabajar en ella, agregando dependencias, librerías, lógica de negocios etc, haciendo que nuestra simple app, se transforme en esto.
- Con el paso del tiempo, lamentablemente nuestra aplicación sencilla muta a algo enorme que nos comienza a quitar nuestro preciado tiempo. Pero debe haber una mejor forma de hacer las cosas no?
- Con el paso del tiempo, lamentablemente nuestra aplicación sencilla muta a algo enorme que nos comienza a quitar nuestro preciado tiempo. Pero debe haber una mejor forma de hacer las cosas no?
- Generalmente cuando se habla de una web application, lo primero que pensamos es en MVC, y eso esta ok, ah probado ser una de los estructuras mas expandidas para aplicaciones web, y de hecho muchos frameworks se basan en estos principios. Pero echemos un vistazo con mas detalle de un tipico codigo mvc.
- En base a lo anterior, podemos notar que nuestra funcionalidad está fuertemente acoplada al contexto web y al entity manager de objetos ORM de una bd relacional. Entonces, que ocurre con la reusabilidad?, como puedo usar este feature en otros contextos?
- Qué ocurriría si estos features fueran necesarios en más contextos?, e.g: Tengo un comando crontab que cada noche revisa usuarios nuevos, creando en forma automática un repositorio, además les envía una notificación por email usando SES y adicionalmente, registra esto en un log no relacional? Simplemente no podría reutilizar.
- Qué ocurriría si estos features fueran necesarios en más contextos?, e.g: Tengo un comando crontab que cada noche revisa usuarios nuevos, creando en forma automática un repositorio, además les envía una notificación por email usando SES y adicionalmente, registra esto en un log no relacional? Simplemente no podría reutilizar.
- En este tipo de arquitecturas a la aplicación no le interesa ni tampoco le es necesario saber con que dependencias conectará afuera, sino más bien,
- Pensemos en esta función que se encarga de editar un objeto de tipo proyecto, la cual es expuesta mediante un endpoint via web. Ciertamente funciona y no parece la gran cosa, pero en realidad si miramos con mayor detalle notaremos la falta de un contexto único que agrupe la idea de “editar un proyecto”. Y esto se aprecia mejor al examinar que este código posee varias llamadas a métodos concretos, o que en sí están relacionado a los detalles de implementación en este caso del entity manager, alejándonos de uno de los principios de OOP, la abstracción. Adicionalmente, podremos notar que este código está fuertemente acoplado al contexto web y una base de datos relacional ORM…. Esto nos deja en serios problemas si mas adelante necesitamos que al crear un repositorio en nuestro sistema se llame a otro sistema externo, e.g: webhook para notificar un cambio.
- Pensemos en esta función que se encarga de editar un objeto de tipo proyecto, la cual es expuesta mediante un endpoint via web. Ciertamente funciona y no parece la gran cosa, pero en realidad si miramos con mayor detalle notaremos la falta de un contexto único que agrupe la idea de “editar un proyecto”. Y esto se aprecia mejor al examinar que este código posee varias llamadas a métodos concretos, o que en sí están relacionado a los detalles de implementación en este caso del entity manager, alejándonos de uno de los principios de OOP, la abstracción. Adicionalmente, podremos notar que este código está fuertemente acoplado al contexto web y una base de datos relacional ORM…. Esto nos deja en serios problemas si mas adelante necesitamos que al crear un repositorio en nuestro sistema se llame a otro sistema externo, e.g: webhook para notificar un cambio.
- Pensemos en esta función que se encarga de editar un objeto de tipo proyecto, la cual es expuesta mediante un endpoint via web. Ciertamente funciona y no parece la gran cosa, pero en realidad si miramos con mayor detalle notaremos la falta de un contexto único que agrupe la idea de “editar un proyecto”. Y esto se aprecia mejor al examinar que este código posee varias llamadas a métodos concretos, o que en sí están relacionado a los detalles de implementación en este caso del entity manager, alejándonos de uno de los principios de OOP, la abstracción. Adicionalmente, podremos notar que este código está fuertemente acoplado al contexto web y una base de datos relacional ORM…. Esto nos deja en serios problemas si mas adelante necesitamos que al crear un repositorio en nuestro sistema se llame a otro sistema externo, e.g: webhook para notificar un cambio.
- Pensemos en esta función que se encarga de editar un objeto de tipo proyecto, la cual es expuesta mediante un endpoint via web. Ciertamente funciona y no parece la gran cosa, pero en realidad si miramos con mayor detalle notaremos la falta de un contexto único que agrupe la idea de “editar un proyecto”. Y esto se aprecia mejor al examinar que este código posee varias llamadas a métodos concretos, o que en sí están relacionado a los detalles de implementación en este caso del entity manager, alejándonos de uno de los principios de OOP, la abstracción. Adicionalmente, podremos notar que este código está fuertemente acoplado al contexto web y una base de datos relacional ORM…. Esto nos deja en serios problemas si mas adelante necesitamos que al crear un repositorio en nuestro sistema se llame a otro sistema externo, e.g: webhook para notificar un cambio.
- Pensemos en esta función que se encarga de editar un objeto de tipo proyecto, la cual es expuesta mediante un endpoint via web. Ciertamente funciona y no parece la gran cosa, pero en realidad si miramos con mayor detalle notaremos la falta de un contexto único que agrupe la idea de “editar un proyecto”. Y esto se aprecia mejor al examinar que este código posee varias llamadas a métodos concretos, o que en sí están relacionado a los detalles de implementación en este caso del entity manager, alejándonos de uno de los principios de OOP, la abstracción. Adicionalmente, podremos notar que este código está fuertemente acoplado al contexto web y una base de datos relacional ORM…. Esto nos deja en serios problemas si mas adelante necesitamos que al crear un repositorio en nuestro sistema se llame a otro sistema externo, e.g: webhook para notificar un cambio.