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
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
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
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.