Arquitectura – Juan Camilo Niño

Cuando construí una plataforma de recaudo de pagos desde cero, lo más difícil no fue React ni Material-UI. Fue descubrir qué tenía que hacer realmente el sistema. El código escrito sobre requisitos equivocados es solo un error bien organizado.

Pregunta primero por el dinero y por el desorden

En todo lo que maneja pagos, empieza por las preguntas incómodas. ¿Qué pasa si un pago falla a la mitad? ¿Quién puede ver qué? ¿Qué debe registrarse y por cuánto tiempo? Esas respuestas moldean la arquitectura mucho más que la elección del framework.

Escribe los recorridos del usuario en lenguaje simple

Antes de cualquier diagrama, escribo cada recorrido como una historia corta: quién es el usuario, qué quiere, qué ve en cada paso, qué puede salir mal. Un cliente puede leer y corregir una historia. No puede corregir un esquema de base de datos.

Convierte las historias en un alcance pequeño y honesto

• Lo que debe existir el primer día.
• Lo que puede esperar a la versión dos.
• Lo que queda explícitamente fuera del alcance, por escrito.

Esa última lista ahorra más discusiones que cualquier otra.

Deja que la IA interrogue el brief

Aquí un asistente es realmente útil. Pego los requisitos y le pido que encuentre contradicciones, casos límite olvidados y preguntas que debería hacerle al cliente. No decide nada, pero encuentra huecos más rápido que yo al final de un día largo.

Elige la arquitectura al final y mantenla aburrida

Cuando los recorridos y el alcance están claros, la arquitectura casi se explica sola: una estructura de componentes que refleja los recorridos, una frontera clara entre la interfaz y los datos, y tan pocas piezas móviles como el problema permita.

Un buen análisis de requisitos se siente lento al principio y ahorra semanas al final. También es la parte del trabajo que la IA menos puede hacer por ti, porque depende de hablar con personas.