Principios y fundamentos de diseño

Te damos la bienvenida al Capítulo 3: Principios y fundamentos de diseño. Toda arquitectura se construye a partir de las mismas pocas ideas sobre la estructura. Cómo dividir un sistema en partes, cuánto deben saber esas partes unas de otras, en qué dirección deben apuntar sus dependencias y cómo mantener el conjunto tan simple como permita el problema. Este capítulo enseña esas ideas.

El Capítulo 2 describió las cualidades que debe ofrecer una arquitectura. La mayoría de ellas, y la modificabilidad por encima de todas, dependen menos de una tecnología concreta que de la estructura. Un equipo puede elegir el framework más de moda y aun así acabar con un sistema en el que cada cambio toca diez sitios. Estos principios son ideas antiguas. La ocultación de información data de mil novecientos setenta y dos, y la ley de Conway de mil novecientos sesenta y ocho. Han sobrevivido porque describen algo que no cambia: el costo de un cambio depende de lo lejos que tenga que llegar ese cambio. Lo que ha cambiado es la escala. El principio que te dice que mantengas privados los campos de una clase también te dice que mantengas privada la base de datos de un servicio. Por eso cada sección muestra cada idea dos veces: en un pequeño fragmento de código y a la escala de los componentes y los servicios.

Este capítulo está pensado para desarrolladores que quieren razonar sobre el diseño con precisión. También está pensado para arquitectos que necesitan un vocabulario común para las revisiones de diseño. Ayuda saber leer ejemplos breves de Python. Se apoya en los atributos de calidad del Capítulo 2, que estos principios ayudan a lograr. Conviene haber leído la sección cero punto tres, sobre cómo organizar el código, y la sección dos punto seis, sobre cómo diseñar para el cambio. Y conduce al Capítulo 4, que muestra cómo describir una estructura para que otros puedan entenderla y cuestionarla.

Las cuatro primeras secciones sientan las bases. La sección tres punto uno se pregunta qué es un módulo y dónde deben ir sus límites. David Parnas demostró que dividir un sistema por pasos de procesamiento fracasa, y que dividirlo por cambios probables funciona. La sección tres punto dos te da el vocabulario para juzgar los límites: los niveles clásicos de acoplamiento y cohesión, y los tipos de acoplamiento que solo aparecen entre servicios. La sección tres punto tres examina la propia interfaz: la ocultación de información, los contratos, las abstracciones con fugas y por qué acaba habiendo dependencias de todo comportamiento visible de una interfaz popular. La sección tres punto cuatro pasa a la dirección: hacia dónde deben apuntar las dependencias, cómo medir la estabilidad, cómo romper ciclos y cómo comprobar todo esto automáticamente.

Este diagrama de la sección tres punto dos muestra el vocabulario en acción, en una refactorización real. A la izquierda está el diseño anterior: un módulo de pedidos y un módulo de facturación. Pedidos llama directamente a Facturación y le pasa un indicador que selecciona uno de dos comportamientos. Así que Pedidos tiene que conocer ese indicador, y no puede aceptar un pedido si Facturación va lenta o está fallando. Peor aún, los dos módulos usan la misma tabla de pedidos. Cualquier cambio en su estructura, sus códigos de estado o sus reglas de IVA tiene que hacerse en los dos módulos a la vez. A la derecha está el diseño posterior. Pedidos publica un evento Order Placed en un intermediario de mensajes, con exactamente los datos que necesita Facturación. Facturación se suscribe, y cada servicio es propietario de sus propios datos. El acoplamiento no ha desaparecido: Facturación sigue dependiendo del significado de ese evento. Pero ahora es explícito, estrecho y versionado, que es lo que significa en la práctica el acoplamiento débil.

Las cuatro secciones siguientes se apoyan en esas bases. La sección tres punto cinco trata los cinco principios SOLID, cada uno mostrado en código y entre servicios, junto con las críticas que reciben cuando se aplican de forma mecánica. La sección tres punto seis presenta la connascence, una medida más fina del acoplamiento, con un conjunto claro de reglas para hacerlo más débil y más local. La sección tres punto siete amplía la mirada a la organización: la ley de Conway, la evidencia que la respalda y la aritmética de las vías de comunicación. La sección tres punto ocho cierra con la simplicidad y la medición: la complejidad propia del problema y la complejidad que añadimos nosotros, el precio de mantener opciones abiertas y los límites de todas las métricas.

Esta es la ley de Conway en una sola imagen. A la izquierda hay una organización. Un equipo de pago y un equipo de catálogo tienen que pasar por un equipo compartido de administradores de bases de datos para cada cambio de esquema. A la derecha está el sistema que construyen: un servicio de pago y un servicio de catálogo que leen y escriben en una base de datos compartida. La estructura del sistema copia la estructura de comunicación. Así que, cuando diseñas un sistema, también estás diseñando quién necesita hablar con quién, y lo contrario es igual de cierto.

Leídas juntas, las ocho secciones forman un solo argumento. El cambio es el costo dominante del software, así que una buena estructura es aquella en la que los cambios probables se mantienen locales. Todos los principios del capítulo son formas de conseguirlo. Por eso también los principios a veces entran en conflicto, y por eso ninguno es absoluto. La habilidad profesional consiste en preguntarse, para un cambio que es probable en este sistema, hasta dónde tendría que llegar y qué principio acorta esa distancia al menor costo.

Si eres nuevo en el diseño, lee las secciones en orden. Cada una empieza con una breve explicación cotidiana. Leer todo el capítulo lleva unas tres horas. Si eres un ingeniero con experiencia, quizá prefieras empezar por los ejemplos prácticos, como la tienda en línea de la sección tres punto uno o el cálculo de métricas de la sección tres punto cuatro. Están pensados para debatirlos. Cada sección termina con unas cuantas preguntas de autoevaluación. Respóndelas mentalmente antes de mirar. Cuando estés listo, haz la prueba opcional del capítulo: veinte preguntas de opción múltiple y dos respuestas escritas, en unos cuarenta y cinco minutos. La nota de aprobado es el ochenta por ciento.

Ese es el mapa del Capítulo 3. Empieza por la sección tres punto uno, sobre la modularidad, donde veremos cómo dividir un sistema para que los cambios que esperas se queden dentro de una sola parte. Nos vemos allí.