¿Reglas o herramientas? El pensamiento crítico en la arquitectura de software

En este artículo, te quiero dar una reflexión crítica sobre la arquitectura de software, un tema de gran relevancia en el mundo del desarrollo de software. En Internet, podemos encontrar una gran cantidad de información sobre patrones de diseño, arquitecturas limpias, DDD, CQRS y muchos otros. Hay muchos tutoriales en los que se habla de estos temas y se ofrecen ejemplos de su implementación en código. En mi opinión, muchos de estos tutoriales son excelentes.

Pero siento que se centran únicamente en los aspectos técnicos y en las ventajas de implementar estas soluciones, sin dejar espacio para la crítica. Esto puede generar una idealización del uso de estas herramientas o estrategias, impidiéndonos verlas como lo que realmente son: referencias que podemos utilizar, en lugar de reglas estrictas que debemos seguir al pie de la letra.

Historia de mi primera base datos en el mundo real

En esta sección, me apartaré brevemente del mundo de la arquitectura de software(Desde perspectiva del código) y compartiré un caso personal que ilustra lo que mencioné anteriormente. Trataré de explicarlo de forma clara y simple para que sea fácil de entender para todos, sin necesidad de conocimientos técnicos avanzados.

Me enseñaron de manera idealista (Mundo perfecto sobre el papel) que una base datos debe distribuir los datos en varias tablas, y que no deberían duplicarse campos en otra tabla porque podría generar inconsistencia.

La primera vez que diseñe una base datos en el mundo real no era muy grande, pero si tenías varias tablas, para una pantalla de un módulo de aplicación se necesitaba incluir el nombre de la empresa, pero para poder acceder a ese campo tenía que pasar por el join de 5 tablas que no necesitaba, solo era para llegar al campo empresaId y luego obtener de la tabla empresa el nombre.

Modelo Empresa
Modelo de Empresa

Como se podría deducir, el campo empresaId solamente estaba presente en una tabla, lo que causaba que la consulta fuera muy lenta en su ejecución, y con mis limitados conocimientos en ese entonces no sabía cómo solucionarlo. Fue entonces cuando alguien me sugirió:

«Agrega ese campo empresaId en todas las tablas, esto reducirá la cantidad de joins necesarios y hará que la consulta sea más rápida. Además, ten en cuenta que esta pantalla no será la única que utilizará ese campo».

Al escuchar esa solución, me parecía inaceptable, porque en mi mundo ideal de teoría de base de datos consideraba que esto era una mala práctica. Para mí, las reglas de modelado de bases de datos no indicaban agregar campos duplicados en varias tablas.

Si hubiera entendido que evitar duplicar campos en otras tablas era una estrategia para evitar posibles inconsistencias, en lugar de una regla que debía seguirse ciegamente, no me habría cerrado a la posibilidad de encontrar una solución y ampliar mis opciones.

¿Este caso como se relaciona con la arquitectura software?

En la arquitectura de software ocurre lo mismo: a menudo se ven como reglas a seguir paso a paso, cuando en realidad son herramientas que podemos utilizar según las necesidades. Por eso, en este primer artículo, quise presentar el contexto e invitar a un poco de pensamiento crítico.

Al igual que en mi experiencia personal, la arquitectura de software también puede volverse compleja y abrumadora. Cuando se trata de tomar decisiones de arquitectura, puede ser tentador seguir patrones de diseño y reglas preestablecidas sin cuestionarlas. Pero cada proyecto de software es único y requiere una solución específica. El pensamiento crítico nos permite analizar y evaluar las opciones disponibles.

También es muy importante recordar que la arquitectura de software es como una caja de herramientas: tenemos muchos elementos, pero no estamos obligados a usarlos todos solo porque sí. Solo debemos utilizar aquellos que se ajusten y nos ayuden a resolver un problema, esa es su razón de existir, no son para generar una complicación adicional innecesariamente en nuestra aplicación.

Conclusión

Creo que es más valioso comprender el contexto del conocimiento y su verdadero propósito, en lugar de enfocarnos únicamente en su implementación. En el campo de la arquitectura de software, existen muchos tutoriales en línea que detallan cómo implementar una determinada técnica de programación paso a paso, pero es más importante comprender por qué y el cuándo de su aplicación. Esto requiere de un pensamiento crítico y consideración de factores como los humanos, económicos y temporales, que influyen en la toma de decisiones.

En las próximas publicaciones, empezaré a exponer mis críticas específicas sobre las arquitecturas limpias DDD y CQRS. Mientras te invito a ver mis otras publicaciones.