Screaming Architecture: Arquitecturas que gritan su propósito
Introducción
Cuántas veces has abierto un proyecto y has pensado: Laravel, Symfony, Django, Rails, NestJS, WordPress…? Y por contra, cuántas veces has abierto un proyecto y has pensado: aplicación de podcast, sistema de venta de tickets, plataforma de alquileres, red social…?
Es bastante común en nuestro mundillo dejarnos llevar por las decisiones que han tomado otros, y por otros me refiero a a los desarrolladores del framework de turno que estemos usando. Arrancamos un proyecto con un framework y directamente nos dejamos llevar por la estructura de directorios y decisiones de arquitectura que más le convenían al equipo que ha desarrollado el framework, en lugar de centrarnos en qué necesita nuestro proyecto para gritar su propósito.
Screaming Architectures
En 2011, Bob Martin proponía el concepto de screaming architecture: arquitecturas que gritan a los cuatro vientos su propósito, el proyecto que modelan, vaya.
El símil más sencillo de entender es el de los planos de un arquitecto: de un solo vistazo se entiende si el diseño corresponde a una casa, un aeropuerto, una plaza, un centro comercial, etc. En ningún momento se habla de materiales. No aún, esos detalles vendrán después. La meta es definir un diseño que cumpla con la especificación del proyecto: un hogar acogedor, un aeropuerto eficiente, una plaza con sombras y bancos, un centro comercial accesible a todo el mundo…
En el campo del desarrollo una buen arquitectura debería de cumplir esos mismos objetivos, ajustarse al sistema que se está modelando, sin importar si la base de datos es MySQL o MongoDB, si usaremos Laravel o Symfony, si usaremos ORMs basados en DataMapper o en ActiveRecord. Nuestra arquitectura debe de poder probarse (testarse) sin haber tomado aún esas decisiones.
El framework solo es una herramienta más
A lo que nos lleva esto es a que debemos considerar el framework que hayamos elegido como una dependencia externa más, no la base sobre la que asentar nuestro dominio. No debemos de tomar las decisiones cruciales en base a las características o funcionalidades que tiene el framework que hayamos elegido, ya que estaremos atándonos a él.
Puede ser tentador, y a todos nos ha pasado, pero ciertamente hay un mundo de ventajas cuando asumimos el control de nuestro dominio, y nos protege contra contratiempos inesperados: dependencias de terceros que se abandonan o que no se actualizan, giros en el diseño que nos afectan de tal manera que no podemos seguir trabajando a no ser que invirtamos tiempo en actualizar al nuevo diseño… etc
Pero no todo es proponerse desacoplarse del framework de turno, tenemos que saber elegir bien nuestras herramientas, ya que muchos frameworks solo funcionan bien si sigues sus reglas y te acoplas a él, y ahí ya depende de nosotros saber si conviene meterse en ese berenjenal, o simplemente dejarse llevar, bien por la duración del proyecto, por las expectativas de crecimiento o simplemente porque es un MVP que desecharemos nada más validemos nuestro negocio.
Si optas por desacoplarte, infórmate bien de tus opciones. Los frameworks que se definen a si mismos como opinionated suelen marcar un modo de trabajo rígido del que es difícil escapar si queremos seguir sacándole partido, y muchas veces es mejor optar por microframeworks que podamos ir ampliando con otras librerías de terceros o con las nuestras propias.
Una buena forma de detectar si será complicado o no desacoplarse del framework, es detectar cuál es su componente principal. Si es un ORM, seguramente sea difícil abstraerse de él, ya que por diseño nos obliga a usar una base de datos, pero si su componente principal es un container de dependencias, ten por seguro que será sencillo, ya que te está dando la herramienta principal para conseguir ese desacople.
Conclusiones
Screaming architecture es más un concepto que una arquitectura en si misma. La única regla que debe de cumplir es gritar su propósito, no ceder el control a un framework, CMS o a una librería que acapare el protagonismo y empuje abajo nuestro dominio de negocio.
No es una tarea sencilla. No siempre va a ser factible. No siempre va a ser rentable. ¿Es una mala idea? En absoluto. En mi experiencia tras haber podido trabajar en proyectos usando este enfoque, he visto que los tiempos de onboarding y adaptación de nuevos desarrolladores es mucho menor, en comparación.
A veces surgen fricciones cuando un desarrollador del framework elegido se une al proyecto y las cosas no se hacen como él acostumbra a hacer, pero su comprensión del dominio es mucho mayor en menos tiempo, y aprender un nuevo workflow es algo que hacemos cada poco tiempo.
Por otra parte, ese control sobre el workflow nos da un extra de independencia a la hora de tomar decisiones relevantes en el diseño de nuestro proyecto y la posibilidad de modificarlo según nuestras necesidades.
En cambio, si el proyecto que afrontas tiene una duración finita, sin posibilidad de expandirse o de crecer, o de añadir más desarrolladores, no dudes en usar las herramientas que consideres para entregar a tiempo, acoplándote y sacándoles todo su jugo.
