Capítulo 3: Metaphor y arquitectura
Capítulo 3: Metaphor y arquitectura
Miércoles. Antes de escribir una sola línea de código, Carlos quiere que el equipo tenga una imagen mental compartida del sistema. En XP esto se llama System Metaphor: una historia simple que todos pueden contar sobre cómo funciona el software.
Anterior: Planning Game inicial | Siguiente: Setup y coding standards
La metáfora del tablero físico
Carlos pone un post-it real en la pizarra.
Carlos (TL): “Imaginen un tablero de corcho en la pared de una oficina. Tiene columnas hechas con cinta adhesiva. Los post-its son las tarjetas. Cada persona puede caminar hasta el tablero, tomar un post-it y moverlo a otra columna.”
Ana (PO): “Así es exactamente como lo usan algunos equipos en la oficina.”
Carlos (TL): “Perfecto. Entonces nuestro software es ese tablero de corcho, pero digital. Cuando hablemos del sistema, usamos las mismas palabras: tablero, columna, tarjeta, mover. No decimos ‘entidad’, ‘modelo’ o ‘componente’ cuando hablamos con Ana.”
Diego (Dev): “¿Y entre nosotros?”
Carlos (TL): “También. Si yo digo ‘la tarjeta se mueve a la columna de Done’, todos sabemos de qué hablo. Si digo ‘el objeto TaskDTO se persiste mediante el repositorio en la tabla tasks’, Ana se pierde y nosotros usamos jerga innecesaria.”
Elena asiente. Ha estado en proyectos donde cada equipo tenía su propio vocabulario y nadie se entendía.
El lenguaje ubicuo
Carlos escribe en la pizarra las palabras que el equipo va a usar siempre:
- Tablero: el espacio de trabajo completo
- Columna: una etapa del flujo (Todo, En Progreso, Hecho)
- Tarjeta: una unidad de trabajo
- Mover: cambiar una tarjeta de columna
- Asignar: vincular una persona a una tarjeta
- Archivar: sacar una tarjeta del tablero activo
Ana (PO): “Me gusta. Son las mismas palabras que usan los equipos en la oficina.”
Elena (Dev): “¿Y en el código usamos estas mismas palabras?”
Carlos (TL): “Exacto. Si la tarjeta se llama ‘tarjeta’ para Ana, se llama ‘tarjeta’ o ‘card’ en el código. No inventamos sinónimos.”
Arquitectura Hexagonal sin jerga
Carlos dibuja un hexágono en la pizarra. Adentro escribe “tablero, columna, tarjeta”. Afuera dibuja flechas que entran y salen.
Carlos (TL): “La idea es simple. En el centro del sistema están las reglas del negocio: qué es un tablero, qué puede hacer una tarjeta, cuántas columnas puede tener. Eso no cambia si usamos una base de datos u otra, o si la pantalla es web o móvil.”
Diego (Dev): “¿Y lo de afuera?”
Carlos (TL): “Los adaptadores. Uno conecta con la base de datos. Otro con la pantalla. Otro con una API. Pero el centro, el dominio, no sabe nada del mundo exterior.”
Ana (PO): “¿Y eso para qué me sirve a mí?”
Carlos (TL): “Para que cuando cambies de opinión sobre cómo se ve la pantalla, no tengamos que reescribir las reglas del negocio. Y para que cuando cambiemos de base de datos, la pantalla siga funcionando igual.”
Ana (PO): “Eso suena a que me protege de cambios costosos.”
Carlos (TL): “Exactamente.”
Simple Design: la regla de Kent Beck
Carlos quiere asegurarse de que el equipo no sobre-diseñe la arquitectura.
Carlos (TL): “Kent Beck tiene cuatro reglas para Simple Design, en orden de prioridad. Primera: el sistema pasa todos los tests. Segunda: revela la intención del programador. Tercera: no tiene duplicación. Cuarta: tiene el menor número de elementos posible.”
Elena (Dev): “¿Eso significa que no hacemos capas de abstracción?”
Carlos (TL): “Significa que hacemos solo las capas que necesitamos hoy. Si hoy solo necesitamos una forma de guardar tarjetas, creamos un puerto para guardar tarjetas. No creamos un framework genérico de persistencia.”
Diego (Dev): “¿Y si después necesitamos más?”
Carlos (TL): “Entonces refactorizamos. Los tests nos protegen. Esa es la belleza de XP: no necesitas predecir el futuro si puedes cambiar el código con confianza.”
Decisiones técnicas del equipo
El equipo discute las herramientas. Carlos facilita pero no impone.
Carlos (TL): “¿Qué opinan de FastAPI para el backend?”
Elena (Dev): “He trabajado con él. Es rápido, tiene buena documentación y se integra bien con tests.”
Diego (Dev): “¿Y para el frontend?”
Carlos (TL): “React. Es lo que ambos conocen. Simplicidad: usamos lo que sabemos, no lo que está de moda.”
Ana (PO): “¿Esas decisiones se pueden cambiar después?”
Carlos (TL): “El frontend sí, porque está fuera del hexágono. El backend también, porque las reglas de negocio están aisladas. Eso es lo que nos da la Arquitectura Hexagonal.”
El equipo no pasa horas comparando frameworks. Eligen lo que conocen y siguen adelante. Mañana empiezan a configurar el entorno.
Práctica XP del capítulo
System Metaphor: Kent Beck describe la metáfora del sistema como una historia compartida que guía todo el desarrollo. No es una analogía forzada: es un vocabulario común que elimina ambigüedades. Cuando todo el equipo, incluido el cliente, usa las mismas palabras para describir el sistema, la comunicación fluye y los malentendidos se reducen drásticamente. La metáfora del “tablero de corcho con post-its” le da a este equipo un ancla mental para todas las decisiones.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Valida que la metáfora coincida con la realidad del negocio |
| Carlos | Propone la metáfora, explica arquitectura en lenguaje simple |
| Diego | Pregunta, aprende, contribuye a la elección de tecnologías |
| Elena | Aporta experiencia técnica, valida las decisiones |
Anterior: Planning Game inicial | Siguiente: Setup y coding standards