Hay proyectos que empiezan con una API, dos controladores y una carpeta llamada Utils.
Seis meses después nadie sabe dónde colocar una regla de negocio sin romper otra cosa.
El problema no es que falten carpetas.
El problema es que nunca se decidió qué responsabilidad tenía cada parte de la solución.
Una estructura multiproyecto sirve para separar lo que cambia por motivos distintos.
Un ejemplo sencillo: una API para un eCommerce
Imagina una API que permite consultar disponibilidad y precio de productos desde una tienda online.
Podríamos dividir la solución así:
Una estructura razonable podría incluir:
- Store.Api: controladores, Swagger, filtros y configuración HTTP.
- Store.Application: casos de uso como consultar producto o reservar stock.
- Store.Domain: entidades, reglas de negocio e interfaces esenciales.
- Store.Infrastructure: acceso a SQL Server, servicios externos y almacenamiento.
- Store.Tests: pruebas unitarias y de integración.
No es una ley universal. Es una forma de impedir que el controlador termine consultando directamente la base de datos, validando descuentos y enviando correos.
Cada proyecto tiene una responsabilidad. Y las dependencias deben apuntar hacia el núcleo, no al revés.
Swagger ayuda a entender y probar la API
Swagger permite documentar los endpoints y probarlos desde una interfaz visual.
En un entorno controlado es muy útil para que desarrollo, QA o un consumidor autorizado comprueben cómo funciona la API.
Pero Swagger no convierte una API en segura.
La seguridad sigue dependiendo de autenticación, autorización, cifrado, validación y control de acceso.
API Key: útil, pero no mágica
Para un caso sencillo entre sistemas, una API Key puede ser suficiente si se utiliza correctamente.
El eCommerce enviaría la clave en una cabecera, por ejemplo X-API-Key. La API comprobaría esa clave antes de ejecutar la operación.
Lo importante es todo lo que no debe hacerse.
Nunca deberías:
- Guardar la API Key en JavaScript visible desde el navegador.
- Subirla al repositorio dentro de un fichero de configuración.
- Compartir la misma clave entre todos los entornos y clientes.
- Escribirla en logs, mensajes de error o capturas.
- Conceder con una sola clave acceso ilimitado a toda la API.
La llamada debe salir desde un backend controlado. La clave debería almacenarse en un gestor de secretos, una variable segura del entorno o un servicio como Azure Key Vault.
Además, debe poder rotarse y revocarse.
Una credencial que no puedes cambiar sin detener el sistema no es una credencial bien gestionada.
La seguridad real está en las capas
La API Key identifica al consumidor, pero no sustituye otras medidas.
La comunicación debe viajar por HTTPS. Los endpoints deben validar datos y limitar operaciones. Conviene aplicar rate limiting, registrar intentos fallidos y separar permisos por cliente.
Para operaciones sensibles puede ser mejor utilizar OAuth 2.0, certificados de cliente o identidades administradas.
La decisión depende del riesgo, no de qué mecanismo resulte más rápido de programar.
El flujo completo
El navegador del cliente solicita un producto al backend del eCommerce.
Ese backend recupera la API Key desde un almacén seguro y llama a la API de catálogo.
La API valida la clave, ejecuta el caso de uso de Application, consulta Infrastructure y devuelve solo la información necesaria.
El navegador nunca ve la clave.
Eso es diseño. No poner cinco proyectos porque queda profesional, sino colocar cada responsabilidad donde puede mantenerse y protegerse mejor.
Una buena arquitectura no evita todos los errores.
Pero hace que los errores sean más fáciles de localizar, probar y corregir.
Y en un sistema que maneja precios, pedidos y clientes, eso vale mucho más que una carpeta bonita.
