Be Wise Apps
Read in English · Lire en français · Auf Deutsch lesen
Sección 1.2 de 1.8 · Principiante · 17 min de lectura
Arquitectura, diseño y código: significancia, alcance y niveles
Videolección
5 min · narrado en inglés, con subtítulosSolo escuchar (audio)
Leer la transcripción
¿Cuándo es una decisión arquitectura y cuándo es solo diseño? Esta lección te da pruebas prácticas y muestra por qué la respuesta no siempre está donde esperarías.
Piensa en el proyecto de una casa. Algunas decisiones fijan todo lo demás: cuántas plantas tendrá, dónde va la escalera, dónde se levantan los muros de carga. Otras se pueden cambiar en un fin de semana: la pintura, las estanterías, las lámparas. Ambas son diseño. Pero solo las primeras son arquitectura, porque cambiarlas después significa hacer obras de envergadura en la casa. En el software, cómo se divide un sistema en partes es arquitectura. Cómo se escribe una función dentro de una parte es diseño.
Grady Booch lo expresó con claridad: toda arquitectura es diseño, pero no todo diseño es arquitectura. No hay un muro nítido entre ambos, solo un continuo de decisiones, ordenado por significancia. Así que la pregunta útil no es si algo es arquitectura en abstracto. Es qué significancia tiene esta decisión aquí y cuánto cuidado merece.
Entonces, ¿qué hace que una decisión sea significativa? Primero, que es difícil o costosa de revertir. Pregúntate: si dentro de un año resulta errónea, ¿cuánto costará cambiarla? Segundo, un alcance amplio. Afecta a muchos componentes, equipos o sistemas, como el formato de los identificadores de cliente que se usan en todos los servicios. Tercero, decide si cumples un objetivo clave de rendimiento, disponibilidad, seguridad o costo. Cuarto, impone una restricción a otros y limita lo que pueden elegir otros equipos. Y quinto, implica compromisos significativos, o verdadera novedad y riesgo, como una base de datos que nadie en la organización ha operado nunca en producción.
Este diagrama sitúa una decisión en el continuo. El extremo izquierdo es más arquitectónico; el derecho es más diseño y código. La primera dimensión es el costo de revertir: meses de trabajo de muchos equipos en un extremo, minutos para una persona en el otro. La segunda es el alcance del impacto: todo el sistema o la organización, frente a una función o clase. La tercera es el efecto en las cualidades clave: ¿la decisión determina alguna, o su efecto es local o nulo? Los puntos sitúan una decisión de ejemplo, la elección del formato de los mensajes, en cada fila. Una decisión puede puntuar de forma distinta en cada dimensión, y por eso hay que mirar las tres.
Así es como el líder técnico de una startup de transporte con conductor clasifica cinco decisiones. Guardar las ubicaciones de los viajes en una base de datos de series temporales es costoso de revertir y afecta a los viajes, la facturación y la analítica. Es arquitectónica, así que se documenta y se revisa. Elegir una biblioteca cliente HTTP dentro del servicio de precios es barato de revertir y afecta a un solo servicio. Eso es diseño, y decide el equipo de precios. Calcular las tarifas en el servidor, nunca en el teléfono, abarca las apps y el backend y protege la integridad de los precios. Es arquitectónica: un principio rector. Representar el dinero como peniques o centavos enteros en todas partes parece un detalle de programación. Pero, en cuanto los datos y los sistemas de los socios dependen de ello, es muy caro de cambiar. Arquitectónica, aunque sea de bajo nivel. ¿Y los colores de modo oscuro en la app de los conductores? Triviales de revertir. Diseño. Fíjate en que dos de las tres decisiones arquitectónicas no tienen nada que ver con cajas y flechas.
La palabra arquitectura también se usa en distintos niveles de alcance, y los cargos siguen esos niveles. La arquitectura empresarial abarca toda una organización: sus capacidades, su información, sus aplicaciones y su tecnología. El marco más conocido en este ámbito es TOGAF, de The Open Group. La arquitectura de soluciones aborda un problema de negocio que abarca varios sistemas, como un hospital que añade la reserva en línea y debe conectarla con sus sistemas existentes. La arquitectura de software o de aplicaciones, tema principal de este curso, se ocupa de las estructuras y las cualidades de un sistema. Por debajo vienen el diseño detallado, dentro de un componente, y después el propio código. Cada nivel restringe al inferior. A la derecha, tres especialidades atraviesan todos los niveles: la arquitectura de datos, la arquitectura de seguridad y la arquitectura de infraestructura.
¿Por qué importa esto? Porque el nivel de abstracción por sí solo es una mala prueba. Los formatos de los identificadores, las convenciones de dinero y de tiempo y los contratos de API son a menudo arquitectónicos, aunque parezcan de bajo nivel. Las decisiones deben tomarse en el nivel más bajo que tenga suficiente contexto y responsabilidad. Los arquitectos que deciden las estructuras de las clases se convierten en un cuello de botella; los equipos que toman por su cuenta decisiones que afectan a todo el sistema crean una incoherencia costosa. Y los buenos equipos reducen el conjunto de decisiones arquitectónicas. Ocultar un proveedor detrás de una interfaz, o mantener una base de datos privada de un solo servicio, hace que una decisión sea barata de revertir y la desplaza hacia el diseño.
Esa es la línea entre la arquitectura y el diseño. La sección completa tiene más decisiones de ejemplo y quién suele tomar cada tipo. A continuación, en la Sección uno punto tres, vemos por qué importa tanto la arquitectura. Nos vemos allí.
Lo que necesitas saber
- La arquitectura y el diseño forman un continuo: toda arquitectura es diseño, pero solo las decisiones de diseño significativas son arquitectura.
- Una decisión es arquitectónicamente significativa cuando es difícil o costosa de revertir, tiene un alcance amplio, determina un atributo de calidad clave, restringe otras decisiones o implica compromisos importantes.
- El nivel de abstracción por sí solo es una mala prueba: convenciones de bajo nivel, como los formatos de los identificadores o de los importes de dinero, pueden ser arquitectónicas, y algunas cajas de alto nivel son triviales.
- Las decisiones estratégicas marcan la dirección a largo plazo para muchas personas; las decisiones tácticas resuelven problemas acotados e inmediatos, pero las elecciones tácticas repetidas pueden volverse arquitectónicas.
- La arquitectura empresarial abarca toda una organización (TOGAF es el marco más conocido), la arquitectura de soluciones un problema de negocio que atraviesa varios sistemas, y la arquitectura de software un sistema; la arquitectura de datos, de seguridad y de infraestructura atraviesan todos los niveles.
- Las decisiones deben tomarse en el nivel más bajo que tenga suficiente contexto y responsabilidad, con una consulta más amplia para las decisiones que afectan a muchos equipos.
Un continuo, no un muro
Si la arquitectura es el conjunto de decisiones y estructuras significativas (Sección 1.1), entonces el diseño es todo lo demás: las numerosas decisiones más pequeñas sobre cómo funciona cada parte por dentro. La dificultad es que no hay una línea nítida entre ambos. Decidir dividir una plataforma de reparto de comida en un sistema de pedidos y un sistema de repartidores es claramente arquitectónico. Ponerle nombre a una variable claramente no lo es. Entre esos extremos hay un amplio terreno intermedio de decisiones (el formato de error de una API, una regla de caché, cómo se divide un módulo en paquetes) cuya naturaleza depende del contexto.
Grady Booch lo expresó con claridad: toda arquitectura es diseño, pero no todo diseño es arquitectura. La arquitectura y el diseño detallado son puntos de un mismo continuo de decisiones de diseño, ordenados según lo significativos que son. Por eso la pregunta más útil no es "¿esto es arquitectura o diseño?" en abstracto, sino "¿qué significancia tiene esta decisión aquí y cuánto cuidado merece?".
Una segunda forma popular de trazar la línea es por nivel de abstracción: la arquitectura es la vista de alto nivel ("cajas y flechas") y el diseño es la vista de bajo nivel ("clases y métodos"). Es una primera aproximación razonable, pero falla en ambas direcciones. Un detalle de bajo nivel puede ser arquitectónico: el formato de un identificador compartido por veinte servicios, o la elección de una convención de zona horaria para las fechas almacenadas, puede costar meses cambiarlo. Y una caja de alto nivel puede ser trivial: que una herramienta interna de administración sea un servicio aparte puede no tener ninguna importancia.
Qué hace que una decisión sea arquitectónicamente significativa
Una decisión es arquitectónicamente significativa cuando tiene una o varias de las características siguientes. No son reglas formales de una sola norma; resumen lo que dicen con distintas palabras el SEI, Martin Fowler, Mark Richards y Neal Ford, entre otros.
Señales de que una decisión es arquitectónicamente significativa
| Característica | Pregunta que hay que hacerse | Ejemplo |
|---|---|---|
| Difícil o costosa de revertir | Si dentro de un año resulta errónea, ¿cuánto costará cambiarla? | Elegir un modelo de datos basado en event sourcing en lugar de almacenar el estado actual |
| Alcance amplio | ¿A cuántos componentes, equipos o sistemas afecta? | Definir el formato de los identificadores de cliente que se usan en todos los servicios |
| Determina una cualidad clave | ¿Decide si cumplimos un objetivo de rendimiento, disponibilidad, seguridad o costo? | Poner una caché delante del catálogo de productos para cumplir un objetivo de respuesta de 200 ms |
| Impone una restricción a otros | ¿Limita lo que pueden elegir otros equipos? | Exigir que todos los servicios publiquen eventos en un único intermediario de mensajes compartido |
| Implica compromisos significativos | ¿Renunciamos a algo importante para obtener otra cosa? | Aceptar la consistencia eventual entre pedidos y existencias para mantener disponible el proceso de pago |
| Mucha novedad o mucho riesgo | ¿Alguien aquí lo ha hecho antes? ¿Y si la tecnología nos falla? | Adoptar una base de datos que la organización nunca ha operado en producción |
Mark Richards y Neal Ford, en Fundamentals of Software Architecture, describen el espectro entre arquitectura y diseño en términos parecidos: una decisión se sitúa más hacia la arquitectura cuanto más estratégica es (a largo plazo, con muchas personas implicadas), cuanto más esfuerzo costaría cambiarla y cuanto más significativos son sus compromisos. Martin Fowler ofrece una versión compacta: la arquitectura es lo que es difícil de cambiar, lo que también significa que uno de los objetivos de un arquitecto es hacer que más cosas sean fáciles de cambiar. Hacer que una decisión sea barata de revertir, por ejemplo poniéndola detrás de una interfaz, la desplaza en la práctica de la arquitectura hacia el diseño. Esta idea, la reversibilidad, se estudia con más detalle en la Sección 1.6.
Situar una decisión en el continuo
Decisiones estratégicas y tácticas
Una distinción relacionada es la que separa las decisiones estratégicas de las tácticas. Las decisiones estratégicas marcan la dirección durante mucho tiempo y para muchas personas: adoptar un proveedor de nube, elegir entre un monolito y servicios distribuidos, decidir que los datos de los clientes se gestionarán como maestros en un único sistema. Normalmente necesitan la opinión de varias partes interesadas y vale la pena ponerlas por escrito con sus razones. Las decisiones tácticas resuelven un problema inmediato dentro de un área acotada: qué biblioteca usar para analizar fechas en un servicio, cómo estructurar una consulta concreta a la base de datos, cómo nombrar los endpoints de una API interna.
Estratégico no significa lento. Muchas decisiones estratégicas pueden y deben tomarse con rapidez una vez que las opciones están claras, y algunas son reversibles si se estructuran bien. Táctico no significa poco importante: una mala decisión táctica repetida en cincuenta lugares (por ejemplo, que cada servicio escriba su propia lógica de reintento sin espera progresiva, o back-off) puede acabar sumando un problema arquitectónico. Los arquitectos vigilan las decisiones tácticas que están a punto de volverse estratégicas por repetición y las convierten en un principio compartido o en una capacidad de la plataforma.
¿Arquitectura o diseño? Decisiones de ejemplo, razonadas
| Decisión (para una tienda en línea) | Veredicto | Razonamiento |
|---|---|---|
| Dividir el sistema en servicios desplegables por separado para el catálogo, el proceso de pago y la entrega | Arquitectónica | Afecta a todos los equipos, al despliegue, a la propiedad de los datos y al comportamiento ante fallos; muy costosa de revertir. |
| Usar PostgreSQL en lugar de una base de datos documental como almacén principal de los pedidos | Arquitectónica | Condiciona el modelo de datos, las transacciones y las habilidades de operación; migrar más adelante es caro y arriesgado. |
| Usar una biblioteca JSON concreta dentro del servicio de pago | Diseño | Es local a un servicio y se puede sustituir en un día si está oculta tras el propio código del servicio. |
| Exigir que todos los servicios emitan logs estructurados con un ID de correlación compartido | Arquitectónica | Una inquietud transversal (cross-cutting concern): solo funciona si todos la siguen, y determina la rapidez con la que se pueden diagnosticar los incidentes. |
| Poner nombre al método que calcula las tarifas de entrega | Diseño (código) | Puramente local; las herramientas automatizan el cambio de nombre. |
| Elegir el formato de los números de pedido que se muestran a los clientes y se comparten con el socio de almacén | Arquitectónica | Es de bajo nivel, pero cruza los límites del sistema y de la empresa y se imprime en los paquetes; cambiarlo requiere coordinarse con un tercero. |
| Usar el patrón Strategy para admitir varias reglas de tarifas de entrega | Diseño | Condiciona el funcionamiento interno de un componente; los demás componentes no se ven afectados. |
| Almacenar en caché los precios de los productos durante 60 segundos | Depende | Diseño si los precios cambian rara vez y que estén desactualizados no causa daño; arquitectónica si un precio desactualizado crea un problema legal o financiero, porque entonces determina una cualidad clave (la corrección). |
Niveles de arquitectura
La palabra arquitectura también se usa en varios niveles de alcance, y los cargos siguen esos niveles. Confundirlos provoca muchos malentendidos: un arquitecto empresarial y un arquitecto de software pueden ser ambos "el arquitecto" y, sin embargo, su trabajo apenas se solapa.
La arquitectura empresarial abarca toda una organización: sus capacidades de negocio (lo que debe ser capaz de hacer, como "evaluar siniestros" o "dar de alta a clientes"), la información que posee, su cartera de aplicaciones y sus plataformas tecnológicas, y cómo deben cambiar todas ellas para respaldar la estrategia. Los resultados típicos son mapas de capacidades, hojas de ruta hacia el estado objetivo, estándares tecnológicos y decisiones sobre qué sistemas retirar. El marco más usado en este ámbito es TOGAF, publicado por The Open Group, cuya versión actual es el TOGAF Standard, 10th Edition (2022). Ofrece un método (el Architecture Development Method) y un cuerpo de contenidos para planificar y gobernar el cambio en la empresa. Las organizaciones lo usan en distinta medida; muchas adoptan partes de él y a algunas les resulta pesado, y este curso solo lo describe para que puedas reconocerlo.
La arquitectura de soluciones aborda un problema o programa de negocio, que normalmente abarca varias aplicaciones, equipos y proveedores: por ejemplo, un hospital que introduce la reserva de citas en línea y debe conectar un nuevo frontend web, el sistema de administración de pacientes existente, un proveedor de SMS y el servicio de identidad. El arquitecto de soluciones hace que las piezas encajen, a menudo con restricciones comerciales y contractuales.
La arquitectura de software o de aplicaciones, tema principal de este curso, se ocupa de las estructuras y las cualidades de un sistema: su descomposición, sus interacciones en tiempo de ejecución, su despliegue, sus datos y su evolución.
Tres especialidades atraviesan todos estos niveles. La arquitectura de datos abarca cómo se modelan, poseen, almacenan, mueven, gobiernan y usan para analítica los datos (Capítulo 7). La arquitectura de seguridad abarca la identidad, el acceso, la protección de los datos, los modelos de amenazas y dónde se sitúan los controles de seguridad (Capítulo 8). La arquitectura de infraestructura (hoy a menudo arquitectura de nube o de plataforma) abarca el cómputo, las redes, el almacenamiento, los entornos y las plataformas de despliegue (Capítulo 10).
Niveles y especialidades transversales
Quién toma cada decisión
En una organización sana, las decisiones se toman en el nivel más bajo que tiene suficiente contexto y responde de las consecuencias. La arquitectura no es propiedad exclusiva de las personas que llevan "arquitecto" en su cargo. Un reparto razonable por defecto es el siguiente, aunque cada organización lo ajusta.
| Tipo de decisión | Normalmente la toma | Normalmente se consulta a |
|---|---|---|
| Estándares y plataformas tecnológicas de la organización (p. ej., proveedor de nube aprobado, plataforma de identidad) | Arquitectos empresariales, CTO, junta de arquitectura | Arquitectos de soluciones y de software, seguridad, finanzas |
| Cómo se combinan varios sistemas y proveedores para resolver un problema de negocio | Arquitecto de soluciones | Product owners, arquitectos empresariales, arquitectos de los proveedores |
| La estructura principal de un sistema: descomposición, estilo de comunicación, propiedad de los datos | El arquitecto de software o el líder técnico del equipo, junto con el equipo | Operaciones, seguridad, otros equipos afectados |
| El diseño dentro de un componente: clases, patrones, algoritmos | El equipo de desarrollo | El arquitecto, solo si está en juego un principio o una cualidad |
| Elecciones a nivel de código: nombres, refactorización local | Cada desarrollador, mediante la revisión de código | Nadie más, normalmente |
Hay dos señales de alerta de que el reparto es incorrecto. Si los arquitectos deciden las estructuras internas de las clases, se convierten en un cuello de botella y el equipo deja de pensar. Si los equipos toman por su cuenta decisiones con efectos en todo el sistema (por ejemplo, que cada uno elija su propio intermediario de mensajes), la organización paga más tarde por la incoherencia. Poner por escrito qué decisiones requieren una consulta más amplia, y facilitar su registro, se trata en decisiones y compromisos y, en profundidad, en el tratamiento de los registros de decisiones de arquitectura (ADR) del Capítulo 4.
Ejemplo práctico
Ejemplo práctico: clasificar decisiones para una app de transporte con conductor
Una startup de transporte con conductor tiene cinco decisiones pendientes. El líder técnico usa las tres señales (costo de revertir, alcance, efecto en las cualidades clave) para decidir cuáles necesitan un registro escrito y una revisión más amplia.
| 1. Guardar las ubicaciones de los viajes en una base de datos de series temporales | Revertir: alto (migración de datos). Alcance: viajes, facturación, analítica. Calidad: rendimiento del seguimiento en vivo. Veredicto: arquitectónica; hay que documentarla y revisarla con el personal de datos y de operaciones. |
|---|---|
| 2. Usar una biblioteca cliente HTTP concreta en el servicio de precios | Revertir: bajo. Alcance: un servicio. Calidad: nada significativo. Veredicto: diseño; decide el equipo de precios. |
| 3. Calcular las tarifas en el servidor, nunca en el teléfono | Revertir: medio. Alcance: apps y backend. Calidad: seguridad e integridad de los precios. Veredicto: arquitectónica; es un principio rector. |
| 4. Representar el dinero como enteros en unidades menores (peniques, centavos) en todas partes | Revertir: muy alto una vez que los datos y las API de los socios lo usan. Alcance: todos los servicios. Calidad: corrección. Veredicto: arquitectónica, aunque sea de bajo nivel. |
| 5. Usar colores de modo oscuro en la app de los conductores | Revertir: trivial. Alcance: un conjunto de pantallas. Veredicto: diseño. |
Dos de las tres decisiones arquitectónicas (3 y 4) no tienen nada que ver con cajas y flechas; son principios y convenciones. El nivel de abstracción por sí solo las habría clasificado mal.
La decisión 4 es del tipo que más a menudo pasa desapercibido: parece un detalle de programación, pero se vuelve muy cara de cambiar en cuanto otros sistemas dependen de ella.
Preguntas frecuentes
¿Es una decisión arquitectónica elegir un lenguaje de programación?
A menudo, sí. Afecta a la contratación, a las bibliotecas disponibles, a las características de rendimiento y a la facilidad con que se puede compartir código entre componentes. En un sistema de muchos servicios independientes, el lenguaje de un servicio pequeño puede ser una elección local; el lenguaje por defecto de toda la organización es arquitectónico.
¿Un esquema de base de datos es arquitectura o diseño?
Depende de quién lo use. Una tabla que solo se usa dentro de un servicio, detrás de su propia API, es diseño. Un esquema que leen directamente varios servicios, informes y exportaciones a socios es arquitectónico, porque cada cambio debe coordinarse entre todos ellos. Muchos equipos hacen que los esquemas sean privados de un solo servicio precisamente para devolverlos al terreno del diseño.
¿El desarrollo ágil significa que no hay arquitectura?
No. Todo sistema tiene una arquitectura; los enfoques ágiles cambian cuándo y cómo se decide, favoreciendo pasos pequeños y reversibles y aplazando las decisiones irreversibles hasta saber lo suficiente. La Sección 1.8 trata este tema.
¿Quién decide si una decisión es significativa?
Normalmente el equipo y su arquitecto o líder técnico juntos, con criterios acordados como las señales de esta sección. Poner esos criterios por escrito evita dos modos de fallo: debatir cada elección y descubrir a posteriori que un equipo tomó por su cuenta una decisión que afecta a todo el sistema.
Cómo aplican la distinción los profesionales
Los equipos con experiencia convierten el continuo en una rutina ligera. Acuerdan una lista breve de los tipos de decisión que necesitan un registro escrito y una consulta más amplia, por ejemplo cualquier cosa que cambie una API pública, introduzca un nuevo almacén de datos o una nueva tecnología, cruce los límites entre equipos o afecte a un objetivo de calidad declarado. Todo lo demás lo deciden las personas que hacen el trabajo, mediante la revisión de código habitual. Revisan la lista cuando algo se les escapa o cuando las revisiones empiezan a parecer burocracia.
También buscan activamente formas de reducir el conjunto de decisiones arquitectónicas, porque cada decisión que pasa a ser barata de revertir es una menos que hay que acertar a la primera. Ocultar un proveedor detrás de una interfaz, hacer que una base de datos sea privada de un solo servicio, usar feature flags para los comportamientos arriesgados y desplegar en incrementos pequeños desplazan decisiones del extremo arquitectónico del continuo hacia el extremo del diseño.
Comprueba lo que has entendido
¿Por qué puede ser arquitectónica una elección sobre el formato de un identificador?
Porque, una vez que muchos servicios, bases de datos y socios externos dependen de él, cambiarlo exige un trabajo coordinado entre todos ellos, así que su costo del cambio y su alcance son altos.
¿Cuál es la diferencia entre la arquitectura empresarial y la arquitectura de soluciones?
La arquitectura empresarial abarca las capacidades, la información, las aplicaciones y la tecnología de toda la organización; la arquitectura de soluciones aborda un problema de negocio que normalmente abarca varios sistemas y equipos.
¿Cómo puede un arquitecto desplazar una decisión de la arquitectura hacia el diseño?
Haciendo que sea más barata de revertir, por ejemplo ocultando una tecnología detrás de una interfaz para que se pueda sustituir localmente.
Fuentes y lecturas recomendadas
¿Tienes una pregunta sobre esta sección? ArchitectBot, el asistente de estudio con IA del curso, responde primero a partir del curso.
Pregunta: “¿Cómo decido cuáles de las decisiones de mi equipo necesitan una revisión de arquitectura y cuáles pueden tomar sin más los desarrolladores?”