Transformar un problema de negocio en casos de uso concretos es una de las habilidades más valiosas que puede desarrollar un profesional de backend. Cuando un cliente describe lo que necesita, rara vez entrega especificaciones técnicas detalladas; entrega una visión. El trabajo del arquitecto y desarrollador consiste en interpretar esa visión, formular preguntas y traducirla en requerimientos que guíen todo el proceso de diseño e implementación.
¿Cómo se interpreta un requerimiento de negocio vago?
El punto de partida es un cliente ficticio llamado Random Camera Reviews, una empresa dedicada a publicar reseñas de cámaras fotográficas en una página web. El escenario plantea lo siguiente [0:42]:
- Editores profesionales crean y publican reviews de cámaras.
- Usuarios finales consumen ese contenido para informarse antes de comprar.
- La empresa ya cuenta con un equipo de front-end; lo que solicita es el desarrollo completo del sistema backend con sus APIs.
Este planteamiento es intencionalmente vago [2:42]. No incluye casos de uso escritos ni diagramas. Eso obliga a quien diseña el sistema a deducir qué se necesita y a generar las preguntas correctas hacia el cliente. La capacidad de extraer requisitos técnicos a partir de descripciones generales es fundamental en cualquier proyecto real.
¿Qué actores y operaciones se identifican?
Al analizar el problema sobre un blackboard, se distinguen dos actores principales [3:15]:
- Ed (el editor): representa a los editores profesionales que envían reviews al sistema en la nube. Su operación principal es la creación de contenido, asociada al verbo HTTP POST [5:13].
- Usuarios: son los consumidores del contenido. No requieren registro ni autenticación; simplemente acceden a los reviews publicados. Su operación se asocia al verbo HTTP GET [4:02].
Estas dos operaciones, get content y post reviews, constituyen los casos de uso esenciales del sistema. Documentarlos con verbos HTTP desde esta etapa temprana ayuda a mantener claridad cuando se pase al diseño de las APIs.
¿Por qué importa la distribución geográfica?
El documento del cliente indica que el mercado más grande se encuentra en América del Sur, pero también existen usuarios en otras regiones del mundo [2:15]. Esto introduce un dato crítico para la arquitectura:
- El sistema debe ser global: usuarios distribuidos en diferentes continentes.
- Los editores operan únicamente desde Suramérica.
- Los usuarios lectores pueden estar en cualquier parte del mundo.
Esta diferencia geográfica tiene implicaciones directas en decisiones de infraestructura como la ubicación de servidores, el uso de redes de distribución de contenido y la latencia aceptable para cada tipo de operación.
¿Qué reto de escalabilidad plantea este sistema?
Uno de los problemas más relevantes que surge del análisis es la asimetría entre lectura y escritura [5:30]. El sistema podría recibir miles o millones de usuarios buscando leer reviews a diario, mientras que la cantidad de editores profesionales podría ser tan baja como diez personas [5:05].
- La lectura de información puede crecer de forma exponencial.
- La escritura de reviews se mantiene relativamente estable y baja.
- Los recursos del sistema deben poder escalar de forma independiente para cada tipo de operación.
Este patrón, donde las operaciones de lectura superan ampliamente a las de escritura, es muy común en aplicaciones web de contenido. Reconocerlo desde la fase de requerimientos permite diseñar una arquitectura que no desperdicie recursos en el lado de escritura mientras refuerza la capacidad de respuesta para los lectores.
¿Cuál es el siguiente paso después de definir los requerimientos?
Toda la información recopilada, los actores, las operaciones, las restricciones geográficas y los retos de escalabilidad, se plasma en un documento de diseño [6:52]. Este documento es el artefacto central donde se detallan los casos de uso, se proponen soluciones arquitectónicas y se justifican las decisiones técnicas.
El proceso que se ha mostrado, leer el problema, dibujarlo, anotar verbos HTTP, identificar volúmenes y distribución, es replicable en cualquier proyecto. Puedes hacerlo en un documento formal, en un cuaderno o en un bloc de notas; lo importante es recabar las ideas y entender qué se está pidiendo antes de escribir una sola línea de código [3:35].
¿Has enfrentado situaciones donde el cliente te entrega requerimientos vagos? Comparte cómo los has resuelto y qué técnicas usas para traducirlos en especificaciones claras.
