Vertical Slices 101

¿De dónde viene el patrón Vertical Slices?

Tras haber hablado durante un tiempo de distintos modelos de Clean Architectures, me gustaría introducir un patrón que discute su eficacia, o al menos sus ventajas a corto/medio plazo.

El patrón Vertical Slices fue creado por Jimmy Bogard como una respuesta a las ya tradicionales arquitecturas limpias (Hexagonal o Ports&Adapters, Onion, Screaming…)

Clean Architecture (siempre según Jimmy), te obliga a seguir una serie de reglas de dependencia que implican crear muchas abstracciones a cambio de muy poco beneficio, ya que el principal objetivo de Clean Architecture es eliminar la dependencia de cualquier framework o librería de terceros.

El beneficio real de estas abstracciones y reglas es difícilmente apreciable, ya que nunca se ha dado el caso de tener que cambiar de Framework o de base de datos (excepto quizá al ejecutar baterías de tests). Pero seguir reglas por seguirlas no va con Jimmy (ni con nadie, supongo), así que propuso su propio modelo de arquitectura.

¿Qué es el patrón Vertical Slices?

Con un patrón de Clean Architecture hacemos una separación por capas, habitualmente Infrastructure (adaptadores de librerías de terceros), Application (lógica de negocio) y Domain (abstracciones y contratos).

La propuesta de Jimmy pasa por, en lugar de dividir nuestro código en capas por cuestiones técnicas, dividirlo por funcionalidad. Cada funcionalidad será una slice y agrupará todas estas capas. De este modo, cada funcionalidad es una caso de uso distinto con distintas necesidades que se abordarán de la forma mas adecuada.

Podría entenderse como un modulo independiente dentro del proyecto, que controla desde la request hasta la response de forma independiente (esto, inevitablemente nos lleva a pensar en CQRS).

La esencia de Vertical Slices Architecture radica en minimizar el acoplamiento entre slices, maximizando a su vez el acoplamiento en cada slice (ejes de cambio).

When adding or changing a feature in an application, I’m typically touching many different “layers” in an application. I’m changing the user interface, adding fields to models, modifying validation, and so on. Instead of coupling across a layer, we couple vertically along a slice. Minimize coupling between slices, and maximize coupling in a slice.

Con este enfoque las capas compartidas desaparecen y las abstracciones se vuelven innecesarias, cada slice implemente únicamente aquello que necesita, y cada slice decide cómo manejar la request que tiene asignada.

Los Domain Logic Patterns de Martin Fowler ya no son una decisión que abarque todo el proyecto, sino que cada slice se autogestiona y decide cuáles usar y cuándo hacerlo. Esto favorece empezar cualquier slice de la forma más sencilla posible e ir refactorizando a patrones a medida que sea necesario, a su debido tiempo.

Desventajas

El propio Jimmy Reconoce que este patrón no es para todos los equipos, ya que estos deben de tener cierta madureza y experiencia en detectar code smells y en aplicar refactors siguiendo las clásicas técnicas del libro Refactoring to Patterns de Joshua Kerievsky, moviendo lógica compleja a una capa de dominio compartido (siempre y cuando sea realmente necesario)

Conclusión

Leer sobre un patrón que contradice una tendencia al alza como las Clean Architectures siempre resulta sumamente interesante, ya que podemos reflexionar sobre lo que estamos haciendo y por qué lo estamos haciendo (¿seguimos reglas por seguirlas?).

No obstante, en mi opinión, este patrón favorece la falta de coherencia entre las distintas funcionalidades de un proyecto, haciendo que tengas que aprender de nuevo cómo está diseñada o implementada en cada una que vayas a tocar.

Puede que sea un enfoque idóneo en proyectos muy grandes con equipos claramente definidos y con formas de trabajar o necesidades claramente distintas, algo así como aplicar microservicios a nivel monolítico pero creo que, en proyectos más pequeños o con una rotación frecuente entre quién va a trabajar en qué funcionalidad, contribuye más al caos.

Sí que me parece un ejercicio interesante desde el punto de vista de que, al pasar por distintas funcionalidades con distintas implementaciones, podemos detectar qué patrones o técnicas están siendo provechosas en otras slices y ver de incorporarlas a otras, eliminando así los patrones implementados solo porque han sido útiles en otra parte de la aplicación. No obstante, me parece un proceso largo que puede tener sentido trabajando en empresas de producto, pero poco favorable cuando trabajamos en proyectos más cortos.