Bienvenidos a una exploración del concepto de «Screaming Architecture». En este blog post, desentrañaremos los fundamentos y la esencia de esta arquitectura que grita su propósito y diseño. Descubre cómo esta metodología desafía las convenciones tradicionales y coloca la funcionalidad por delante de la tecnología. A lo largo de este viaje, exploraremos ejemplos concretos y casos de uso que ilustrarán cómo Screaming Architecture promueve la claridad, la flexibilidad y la sostenibilidad en el desarrollo de software. Prepárate para sumergirte en un enfoque arquitectónico que no sólo comunica su propósito, sino que también se erige como un paradigma revolucionario en la construcción de sistemas robustos y orientados a la evolución. ¡Acompáñanos en este recorrido hacia una arquitectura que resuena con propósito y eficiencia!
Como desarrolladores, invertimos una cantidad significativa de tiempo examinando el código elaborado por otros. En la mayoría de los casos, este código forma parte del proyecto en el que actualmente estamos inmersos, lo que implica que lo conocemos bastante bien. No obstante, en ciertas ocasiones, nos encontramos con un proyecto completamente nuevo. Es en estos momentos cuando una arquitectura expresiva facilita en gran medida nuestra labor.
La expresión «arquitectura expresiva» se emplea cuando, con tan solo echar un vistazo a un nuevo proyecto, podemos obtener una impresión central de su propósito y funciones principales. Este término fue acuñado por Robert C. Martin, también conocido como Tío Bob, y puedes encontrar más detalles al respecto aquí. Se refiere a la manera en que estructuramos nuestro proyecto para que podamos captar información valiosa desde el inicio de la navegación, dejando los detalles de implementación para las partes «más difíciles de alcanzar». Imagínalo como si estuvieras narrando la historia del proyecto a un nuevo miembro. ¿Cómo lo explicaríamos durante su proceso de integración? ¿Podemos, en cambio, realizar este recorrido a través de la estructura de nuestro proyecto?
Consideremos la gestión de un negocio especializado en el alquiler de vehículos, al cual dotamos con una solución de software que aborda diversos aspectos de este sector, con el objetivo de brindar un servicio de alquiler de vehículos. Óptimamente, nos empeñemos en detallar los términos «automóvil», «solicitud», «acuerdo», «cliente», «sedes», «oficina central», en las carpetas principales de la estructura de nuestro proyecto. Una vez más, esto es independiente del lenguaje de programación, la arquitectura utilizada o la naturaleza del proyecto. La estructura del proyecto que conduce a la especificidad de estos conceptos, mediante, por ejemplo, carpetas en la estructura de archivos, sería una arquitectura resonante. En contraste, si nos encontramos con nombres de marcos como «Angular», «Django», o términos genéricos como «elementos», no estamos comunicando nada acerca del ámbito, del propósito de la aplicación.
Una ventaja significativa de una arquitectura llamativa es su capacidad para suavizar la pendiente de introducción al proyecto. En la actualidad, la incorporación al proyecto se simplifica considerablemente, dado que la esencia del software queda clara en su estructura; su propósito, los problemas que aborda y los diversos componentes conceptuales del ámbito que estamos representando. Otro beneficio radica en que, una vez inmersos en el proyecto, podemos analizar la ubicación de una característica específica o determinar qué sección del software podría verse afectada por un error de manera más accesible. Esto se facilita, ya que la lógica que influye en una parte específica del sistema se encuentra delimitada dentro de ciertos confines que, nuevamente, se explicitan en la estructura del software.
Entonces, ¿cómo podemos concebir una estructura arquitectónica que cause un fuerte impacto? La cuestión no radica en el tipo de arquitectura que implementamos en un proyecto, sino más bien en «cómo» lo organizamos. Claro, se necesita realizar una labor de modelado del dominio y diseño del sistema. Este es realmente el trabajo que demanda la experiencia de los diseñadores de software, y existen numerosas metodologías al respecto que podemos abordar en otra publicación. Para ilustrar con ejemplos concretos, examinemos detenidamente estos dos proyectos:
Si evaluamos el proyecto «sin impacto», ¿qué podemos inferir de él a primera vista? ¿Esta disposición del proyecto nos proporciona mucha información sobre la problemática que aborda? Identificamos el uso de Django, lo que indica la adopción de un marco. También notamos la utilización de una base de datos, con algunos modelos presentes, que, al tener conocimiento de Django, asumimos que representan las entidades que constituyen los datos de la aplicación. Además, se percibe la existencia de una API web, lo que sugiere la posible exposición de una API hacía algún front-end. Podemos presuponer la presencia de lógica de aplicación en la carpeta denominada «negocio», la cual alberga reglas de negocio y utilidades. La información más destacada que podemos discernir incluye los archivos relacionados con un vehículo de alquiler y un back office en la carpeta de controladores, dentro de la API web. Ahora examinemos una estructura de proyecto más sugerente.
Si examinamos este segundo ejemplo, el proyecto denominado «llamativo» adopta un enfoque diferente en la forma en que estructura su organización. Ahora no se presentan referencias a marcos, lenguajes o tecnologías como bases de datos o API web. Lo que se visualiza a simple vista son entidades del negocio y acciones que pueden ocurrir. En el primer nivel, se distinguen dos secciones: un «centro administrativo», que podría ser interpretado como una sección administrativa, y un «arrendamiento de vehículos». En el centro administrativo encontramos contratos (quizás los tipos de contratos disponibles) y sedes (quizás las ubicaciones físicas de la empresa). En el arrendamiento de vehículos, tenemos vehículos y clientes, seguidos por las acciones que acontecen en el negocio. Así que un concepto es «arrendar un vehículo», y otro es «crear un cliente». Estos conceptos se explicitan únicamente a partir de la estructura del proyecto. Nuevamente, este es un ejemplo ilustrativo, ya que en el mundo real no es tan sencillo estructurar un proyecto, dado que entran en juego numerosos elementos, lo que requiere una cuidadosa reflexión, además del conocimiento del negocio y la experiencia en el diseño de software.
Conclusiones
En conclusión, Screaming Architecture emerge como un paradigma arquitectónico que enfatiza la claridad y la comprensión intuitiva en el desarrollo de software. Sus ventajas radican en la capacidad de comunicar de manera efectiva el propósito y la funcionalidad del proyecto, facilitando la colaboración y reduciendo la complejidad cognitiva para los desarrolladores. La estructura transparente permite a los equipos orientarse rápidamente en proyectos nuevos, mejorando la mantenibilidad y la evolución a largo plazo.
Sin embargo, no está exento de desafíos. Las desventajas incluyen la necesidad de una cuidadosa planificación y diseño inicial, ya que una mala implementación podría llevar a una arquitectura confusa. Además, en proyectos muy complejos o con requisitos específicos, la rigidez de las reglas de Screaming Architecture podría parecer restrictiva. La claridad proporcionada por esta arquitectura puede, en algunos casos, requerir una inversión de tiempo inicial significativa.
En última instancia, la adopción de Screaming Architecture dependerá de la naturaleza del proyecto y de la preferencia por un enfoque que prioriza la claridad y la comunicación sobre otros factores.
