Por qué dejé de escribir código y empecé a diseñar
Solía pensar que el desarrollo de software consistía en escribir funcionalidades. Pensaba que mi trabajo era crear entidades, construir controladores y conectar bases de datos.
Un proyecto reciente cambió mi perspectiva. Aprendí que programar es solo una parte de la solución. El verdadero trabajo ocurre antes de escribir una sola línea de código.
Debes decidir la arquitectura. Debes preguntarte por qué encaja, qué coste tiene y qué riesgos resuelve.
Aquí están mis principales lecciones:
• La arquitectura debe ajustarse a la etapa del producto. Es tentador utilizar microservicios, Kubernetes y colas de eventos complejas de inmediato. Para nuestro proyecto, elegimos una arquitectura por capas en un único proceso. Esto nos permitió separar responsabilidades sin el dolor de cabeza de un sistema distribuido. Lo simple suele ser mejor cuando se empieza.
• Algunas decisiones son económicas ahora pero costosas después.
Añadimos un TenantId a nuestro modelo de datos desde el primer día. Aunque solo teníamos un cliente, esto facilitó una futura transición a un modelo SaaS. Si esperas demasiado para añadir la multi-tenencia, la migración se convierte en una pesadilla.
• El diseño evita callejones sin salida en el futuro. La programación resuelve un problema inmediato. El diseño resuelve un problema sin cerrar puertas al futuro. Utilizamos contenedores desde el principio para facilitar el cambio a diferentes infraestructuras. Utilizamos interfaces para que el cambio de proveedores fuera sencillo.
• Los cambios de negocio impulsan los cambios técnicos. Un sistema pasa a microservicios porque el negocio crece. Una aplicación para una sola clínica se convierte en una plataforma SaaS para cientos de clínicas. Este cambio altera la forma en que gestionas la facturación, las suscripciones y el escalado.
• La fiabilidad requiere patrones inteligentes. Pasamos de llamadas síncronas a una arquitectura orientada a eventos. En un sistema médico, un servicio de notificaciones lento no debería bloquear la reserva de una cita. Utilizamos el patrón Outbox para garantizar que los datos permanezcan seguros incluso si el broker de mensajería falla.
• Los patrones deben adaptarse al dominio. No utilices patrones a ciegas. Un diagnóstico médico requiere una consistencia fuerte. No puedes confiar en la consistencia eventual para la seguridad del paciente. No utilices caché para datos clínicos sensibles si esto rompe tu pista de auditoría.
• DevOps no es algo que se deja para el final. El despliegue, los health checks y los pipelines son parte del diseño inicial. Debes estimar los costes y elegir componentes que realmente cubran tus necesidades.
La diferencia entre un programador y un diseñador es el "porqué".
Un programador pregunta: "¿Cómo hago que esto funcione?". Un diseñador pregunta: "¿Por qué esta es la solución adecuada para este problema específico?".