La capas no es un concepto novedoso. Ha existido en la industria durante m谩s de un par de a帽os (algunos de ustedes que leen este documento son probablemente m谩s j贸venes que las capas) y es uno de los primeros estilos arquitect贸nicos creados. En resumen, las capas no son m谩s que dividir las responsabilidades de su aplicaci贸n en diferentes capas, donde las capas superiores pueden hablar con las capas inferiores, pero no al rev茅s.
Las capas interact煤an a trav茅s de fachadas, por lo que una capa no tiene que saber nada sobre los detalles de implementaci贸n interna de otras capas.
Traducir esto en una aplicaci贸n React, lo que haremos es tener una capa de UI donde vivir谩n los componentes con la reactividad propia de React, donde escribiremos componentes de react con nada de l贸gica de negocio. Detras de esta capa tendremos una capa de aplicaci贸n donde modelaremos los casos de uso de la aplicaci贸n, aqu铆 comenzaremos a interactuar con nuestra l贸gica de negocio, y por 煤ltimo tendremos nuestra capa de dominio, donde aqu铆 estar谩 lo m谩s importante de nuestra aplicaci贸n, porque esta capa no deber谩 tener ning煤n tipo de dependencias externas.
Para una peque帽a aplicaci贸n, tal vez tener una capa de ui y otra de domino o view model alcanzar谩, y probablemente es c贸mo hemos estado escribiendo aplicaciones React durante mucho tiempo. Pero a medida que crecen las aplicaciones, estas capas siguen siendo m谩s gruesas y comienzan a hacer demasiado, lo que hace que sean m谩s dif铆ciles de razonar.
Antes de continuar, me gustar铆a hablar un poco acerca de los beneficios de separar en capas nuestro proyecto.
Divide y conquista: la mejor manera de resolver un gran problema es dividirlo en problemas m谩s peque帽os que son m谩s f谩ciles de resolver. Podemos razonar sobre una capa de forma independiente sin preocuparnos por la implementaci贸n de otras capas.
Las capas se pueden sustituir f谩cilmente con implementaciones alternativas. No es como si estuvi茅ramos cambiando nuestra biblioteca HTTP todos los d铆as, pero cuando llega el momento, el cambio se aut贸nomo dentro de una capa y nunca debe filtrarse fuera de los l铆mites de la capa. La refactorizaci贸n se vuelve m谩s f谩cil y menos intrusiva.
Las arquitecturas que escala deben tener la capacidad de evolucionar a medida que el software madura y los requisitos cambian. Aunque nos gusta hacer algo de dise帽o por adelantado, hay cosas que solo aparecer谩n despu茅s de que comience el desarrollo. Al usar capas, podemos retrasar las decisiones sobre los detalles de implementaci贸n hasta que tengamos suficiente informaci贸n para tomar una decisi贸n sensata.
Las dependencias entre capas se controlan ya que son unidireccional. Apuntar a un bajo acoplamiento (mientras se mantiene una alta cohesi贸n) es una buena manera de evitar que nuestra aplicaci贸n se convierta en una gran bola de barro.
Tener una arquitectura en capas permite probar cada componente de forma aislada y f谩cil. Aunque esto es bueno, en mi opini贸n no es el mayor beneficio en t茅rminos de prueba. Para m铆, el mayor beneficio de las arquitecturas en capas es que es m谩s f谩cil escribir pruebas mientras trabajas en el c贸digo. Dado que cada capa debe tener una responsabilidad bien definida, es m谩s f谩cil pensar en lo que vale la pena probar durante la implementaci贸n.
Todas las cosas mencionadas anteriormente nos ayudan a escribir un c贸digo que es m谩s f谩cil de mantener. Una base de c贸digo mantenible nos hace m谩s productivos, ya que pasamos menos tiempo luchando contra la deuda t茅cnica y m谩s tiempo trabajando en nuevas caracter铆sticas. Tambi茅n reduce el riesgo al introducir cambios. Por 煤ltimo, pero no menos importante, hace que nuestro c贸digo sea m谩s f谩cil de probar, lo que en 煤ltima instancia nos da m谩s confianza durante el desarrollo y la refactorizaci贸n.
Ahora que conocemos los beneficios de las capas y las arquitecturas en capas, hablemos sobre qu茅 tipo de arquitectura en capas estamos proponiendo para una gran aplicaci贸n React.
La arquitectura limpia es un tipo de arquitectura en capas compuesta por varias ideas de otras arquitecturas en capas, como arquitectura de cebolla, arquitectura hexagonal y arquitectura de puertos y adaptadores, entre otros.
La idea central detr谩s de Clean es poner el negocio y las entidades de negocio en el centro de nuestra aplicaci贸n. Las capas externas son menos espec铆ficas para el negocio, mientras que las capas internas tienen que ver con el negocio.
Describiremos brevemente lo que cada capa hace en arquitectura limpia, para comprender c贸mo podemos aprovechar algunos de estos conceptos en nuestras aplicaciones React.
Pero antes me gustar铆a comentar el tipo de relaci贸n que habr谩 entre la vista y los uses cases; Para ello nos basaremos en la estructura MVVM Model-View-ViewModel.
Esta estructura es muy facil de entender, La vista simplemente se encarga de presentar la informaci贸n resibida por el ViewModel, El ViewModel es el principal responsable de definir la l贸gica de presentaci贸n y el manejo del estado interno de esta vista, y dialogar con el Modelo, donde all铆 se encontrar谩 la l贸gica de negocio.
Arquitectura limpia, un diagrama
En el centro del diagrama tenemos entidades.En la arquitectura limpia cl谩sica, las entidades son una media de contener el estado relacionado con las reglas de negocio. Las entidades deben ser estructuras de datos simples y no tener conocimiento de nuestro framework o librer铆a de UI.
Para una aplicaci贸n frontend, aqu铆 es donde tenemos la l贸gica relacionada con las entidades de nuestro sistema.
Los casos de uso est谩n cerca de las historias de usuarios en terminolog铆a 谩gil. Aqu铆 es donde viven las reglas del negocio de la aplicaci贸n. Un caso de uso debe representar algo que un usuario quiere lograr. Los casos de uso deben tener todo el c贸digo para que eso suceda de una manera que tenga sentido para la aplicaci贸n. Observe que los casos de uso solo pueden depender de las capas internas, por lo que para que las cosas ocurran dentro de un caso de uso (digamos que haga una solicitud HTTP) tenemos que inyectar dependencias en nuestro caso de uso y aplicar inversi贸n de control.
Esta capa contiene c贸digo de nuestro framework o librer铆a que implementa los casos de uso. Por lo general, la capa de UI llamar铆a los m茅todos expuestos por los controladores o presentadores.
La capa m谩s externa es donde est谩n contenidas todas las operaciones de IO. Entrada del usuario, conexiones HTTP, lectura de un almacenamiento web, etc. Aqu铆 es donde vive nuestro framework de la interfaz de usuario.
Vale la pena se帽alar que, como cualquier otra arquitectura en capas, podemos agregar tantas capas como sea necesario. Aunque cuanto m谩s simple, mejor!.
- Martin Fowler -- Catalog of Patterns of Enterprise Application Architecturehttps://martinfowler.com/eaaCatalog/domainModel.html
- Denis Brandi -- Why you need use cases interactorshttps://proandroiddev.com/why-you-need-use-cases-interactors-142e8a6fe576
- Bob Martin -- The Clean Architecturehttps://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- Daniel Mackay -- Clean Architecture, an introductionhttps://www.dandoescode.com/blog/clean-architecture-an-introduction/
- CodingWithMitch -- 2 Key Concepts of Clean Architecturehttps://www.youtube.com/watch?v=NyJLw3sc17M
- Frank Bos and Fouad Astitou -- Fuck CLEAN Architecturehttps://www.youtube.com/watch?v=zkmcy9WQqUE
- Ian Cooper, The Clean Architecturehttps://www.youtube.com/watch?v=SxJPQ5qXisw