Dentro del desarrollo tenemos muchas formas de estructurar una aplicación, una de ellas es estructurar nuestra aplicación por funcionalidades, aquí es donde entra Vertical Slice Architecture o Arquitectura Vertical.
Índice
1 - Qué es la arquitectura vertical?
Utilizar arquitectura vertical implica que vas a definir la estructura de tu proyecto en capas verticales o como se denomina en inglés slices.
No hay que confundir con otras arquitecturas que basan su estructura en capas, o en inglés layers, las cuales suelen referirse a capas horizontales.
Estas capas verticales, contienen toda la lógica de una funcionalidad, desde la capa de interfaz, como las de dominio o el acceso a datos y la representación más común que se suele hacer es con una tarta, ya que cuando cortas una tarta tienes un slice que contiene todas las capas.
Es muy común ver una representación tal que así:
Que en mi opinión es una representación paupérrima, ya que lo primero que veo yo al ver eso es 3 capas (layers) y que cada funcionalidad tiene una parte en una capa…
Pero eso no es vertical slice architecture, eso es layered architecture.
La idea principal de esta arquitectura es agrupar toda la lógica de cada funcionalidad junta, lo que permite que sea muy fácil de identificar dónde estamos trabajando, o qué tenemos que modificar.
Y personalmente pienso que, esta imagen reprsenta lo opuesto, en teoría no vamos a compartir las diferentes capas como es presentación, datos, infra, etc, pero cuando yo miro la imagen es todo lo que veo.
Para mi, una representación fiel de Vertical Slice Architecture es la siguiente:
Donde claramente vemos la separación de capas por funcionalidades, siendo las capas repetidas (si hace falta) en cada funcionalidad.
El gran problema que veo cuando se explica el concepto de Vertical Slice Architecture es que se explica junto a clean/onion architecture. Incluir una capa de infraestructura y que el proyecto que llama a dicha capa no tiene conocimiento de la implementacion es Clean Architecture. y como la mitad de los post que hay por ahí son copias de otros, pues todos caen en el mismo problema y no lo saben separar una de la otra. Pero esto da para un libro porque pasa exactamente lo mismo con CQRS y event sourcing o CQRS y mediatr, como si no se pudiera hacer uno sin lo otro.
Ojo que no está mal mezclar ambas arquitecturas, solo que cuando se explican deberían estar bien diferenciadas.
Por lo que a mi respecta, si estás haciendo vertical slice architecture y tus elementos son simples, por ejemplo un DTO de una línea, un mapper de una línea, un acceso a datos de una línea y la lógica de una línea, puedes hacerlo todo en el mismo fichero.
2 - Ventajas de la arquitectura vertical
En el caso de la imagen mostrada anteriormente, si entendemos cada feature como un proyecto (aunque estén en el mismo csproj), podemos definir como mejor convenga la forma de acceder a los datos o el uso de request responses. Mucha gente (incluido el propio Jimmy Bogard, creador de VSA) especifican que esta arquitectura te lleva a implementar CQRS de una forma natural y automática. Respecto a esto voy a contar un secreto, no se como se hacía software hace más de 15 años, pero desde que yo empecé profesionalmente, siempre he separado las lecturas de las escrituras 🤷, por sentido común principalmente.
Tener esta separación por funcionalidades va a permitirnos además que los cambios que realicemos no afecten a otras funcionalidades lo que facilita la iteración, sobre todo si estamos trabajando en un molito o un microlito,
Con esta separación llegado el día se puede separar a un proyecto individual de una forma más o menos sencilla.
Por lo tanto facilita la migración a monolitos modulares o incluso una separación de los propios servicios si se diera el caso, lo que implicaría una desarrollo e integración continúa de la funcionalidad en sí.
3 - Mi opinión de Vertical Slice Architecture
Esta vez va a ser sencilla, mi única crítica es que una separación tan radical no siempre funciona bien y quizá ciertas partes del dominio sean compartidas para así no duplicar información muchas veces.
Al margen de eso todo me parece bien ya que cada funcionalidad es dueña de su código, que traducido al mundo real, cada equipo es dueño de su código y no se ven forzados a implementar patrones completamente innecesarios porque otra parte del sistema los implementa.
