Estratificar correctamente una aplicación, especialmente en el frontend, te proporciona posibilidades infinitas en cuanto a escala y mantenibilidad. Saber cómo funcionan las capas en el Desarrollo de Software te ayudará a crear sistemas que sean comprensibles, no solo para los humanos sino también para la IA.
Las capas en la Arquitectura de Software aportan estructura, te permiten cambiar el sistema sin afectar a partes no relacionadas y crean contextos con los que es más fácil razonar.
Entendamos las capas, juntos.
#¿Qué son las capas?
Si pensamos en lo que las capas realmente son... Son autolimitaciones. Nos limitan desde dónde podemos importar código.
¿Por qué querríamos limitarnos? ¿Por qué no debería importar código de un lugar que considero que es otra capa? ¿Sería tan terrible llamar a fetch directamente desde mis componentes de UI? ¿Cuál es el valor de esto?
Las capas agrupan el código dependiendo de una razón principal:
Con qué frecuencia cambia ese código.
#¿Qué valor aportan las capas?
Cuando hablamos de cambio, en realidad estamos hablando de estabilidad. Si una capa tiende a cambiar mucho, podemos decir que tiene baja estabilidad. Si una capa no cambia tanto, entonces es una capa estable.
Cuando trabajamos con capas, lo que estamos modelando es la relación entre capas más estables y capas menos estables. Esto es algo que no debe pasarse por alto. Déjame preguntarte lo siguiente:
Si estamos en una capa muy estable, e importamos código de una capa muy inestable, ¿qué sucede?
Acabamos de hacer que una capa que no necesitaba cambiar (estable) tenga de repente una relación directa con una capa que cambia mucho (inestable). Ahora, cuando cambiemos la capa inestable (lo cual sucederá con bastante frecuencia), necesitaremos cambiar la capa (in)estable cuando eso no debería haber sido así.
#¿Cómo podemos implementar capas?
En un proyecto dado, podemos tener diferentes capas, entonces, ¿cómo se ven realmente? Bueno, aunque las capas pueden ser conceptuales, me gusta hacer las mías como carpetas.
src layer-a layer-b layer-c
Si estos nombres no aportan claridad por ahora, no te preocupes; son solo marcadores de posición. Te mostraré exactamente qué capas uso en mis proyectos de Frontend en un momento. Siento que es más ilustrativo que nos mantengamos enfocados en el concepto en lugar de en los nombres detallados.
Creo que es más claro tener una carpeta que simplemente recordar qué archivos pertenecen a qué capa.
#¿Cuál es la relación entre las capas?
Típicamente, las capas se han representado como círculos concéntricos para representar la relación entre ellas. Exploremos ese concepto.
Cuando me presentaban este gráfico, siempre estaba confundido, si en nuestra base de código tenemos tres capas que parecen ser hermanas, ¿cómo es que aquí están anidadas?
La respuesta es sencilla, este gráfico representa de dónde pueden importar código las capas.
¿Recuerdas lo que dijimos anteriormente?
“”Si estamos en una capa muy estable, e importamos código de una capa muy inestable, hacemos nuestra capa estable, inestable
En la práctica esto significa que las capas más externas son las más inestables, mientras que las más internas son las más estables.
En este caso, layer-a es más inestable que layer-b y layer-c.
Así que podemos decir que el conocimiento entre capas es hacia adentro.
De nuevo, en la práctica, esto significa que solo puedo importar código de capas que sean más estables que yo.
Así que, no puedo importar nada desde layer-c. Desde layer-b solo puedo importar desde layer-c. Y desde layer-a puedo importar código de layer-b y layer-c.
#¿Cómo debería llamar a mis capas?
Ahora que hemos entendido las capas, elijamos un nombre más apropiado para ellas.
En Arquitectura Frontend, la capa más central que representa mi lógica de negocio, reglas, invariantes, entidades, etc., la llamo:
domain
Por encima de esta capa, donde coloco mis casos de uso, lógica de estado, reglas y código de permisos, la llamo:
application
Luego, el mecanismo que uso para entregar mi aplicación al usuario final, lo llamo:
delivery
Suelo tener otra capa llamada infrastructure (infraestructura), donde coloco mis implementaciones de repositorio
Vamos a refactorizar renombrar (Shift + F6) las capas para que tengamos la imagen final:
#¿Cuáles son los beneficios de usar capas?
Te preguntarás, ¿por qué hacer todo esto?
Bueno, digamos que hemos construido una aplicación web donde los casos de uso están separados nítidamente en la capa de aplicación, lo que significa que cada acción que realiza el usuario está abstraída en un caso de uso.
Ahora mismo nuestro mecanismo de entrega es una interfaz web usando React. Dados estos tiempos, ahora debemos implementar un agente de IA. Nada cambia, los casos de uso son los mismos, la lógica es la misma, pero el agente de IA se expone de manera diferente a una aplicación web.
¿Necesitaríamos duplicar el proyecto? Eso no sería sabio, ya que si queremos hacer un cambio en un proyecto, ahora necesitamos cambiar dos.
No, un mejor enfoque sería crear dos entregas (deliveries):
src application delivery ai-agent webapp domain
Con este enfoque, ai-agent y webapp reutilizan los mismos casos de uso y llaman a los mismos objetos de dominio, simplemente lo hacen de una manera diferente.
Es simplemente tan limpio.
#Conclusión
Como hemos visto, las capas no solo proporcionan claridad, sino que son puntos de extensión tremendos para nuestra arquitectura, para que sea ágil pero sólida.
En el siguiente número exploraremos cómo las capas se pueden combinar con módulos de características para crear sistemas verdaderamente modulares.
P.D: Acabo de lanzar la mejor peor landing jamas hecha para mi libro Software Cafrers. Échale un vistazo aquí: https://www.softwarecafrers.com/Se abre en una nueva pestaña.