Con los requisitos y la planificación de la lección anterior ya cerrados, esta lección ensambla la Iteración 2 completa: la API de BiblioTech. No se escribe lógica de dominio nueva —todo el comportamiento ya existe en Biblioteca, en IRepositorioBiblioteca y en sus implementaciones—; el trabajo consiste en organizar ese código en una estructura de solución con varios proyectos, registrar correctamente las dependencias en el contenedor de DI de ASP.NET Core (retomando 07-03 y 08-03), y exponer un endpoint por cada uno de los siete requisitos funcionales definidos en la Lección 2.

1. Estructura de la solución: varios proyectos .NET
2. BiblioTech.Dominio: el modelo ya construido, sin cambios
3. BiblioTech.Persistencia: IRepositorioBiblioteca y sus cuatro implementaciones
4. BiblioTech.Api: registrando servicios en el contenedor de DI
5. Endpoints: catálogo, socios, préstamos, devoluciones, metadatos
6. Program.cs completo
7. Aplicando patrones y estándares ya vistos

Hasta ahora, cada lección del curso trabajó con un único proyecto de consola o un único proyecto de la tecnología de turno. Un proyecto real de este tamaño se organiza mejor en varios proyectos .NET separados, agrupados en una solución (.sln), cada uno con una responsabilidad propia —el mismo principio de responsabilidad única de 08-01, aplicado ahora a nivel de proyecto en vez de a nivel de clase:

Las flechas del diagrama son direcciones de dependencia (dotnet add reference): Dominio no depende de ningún otro proyecto —ni siquiera sabe que existe persistencia o una API—, mientras que Persistencia y Api dependen de él. Esta dirección no es casualidad: es exactamente el mismo principio que motivó extraer IRepositorioBiblioteca en 08-03, ahora aplicado a la organización de carpetas y proyectos, no solo a las clases dentro de un único proyecto. Un proyecto opcional BiblioTech.Web (un cliente Blazor) se trataría exactamente igual: dependería solo de lo estrictamente necesario para consumir la API por HTTP, sin referenciar directamente BiblioTech.Dominio ni BiblioTech.Persistencia (el cliente no conoce esas clases: solo conoce los DTOs que la API expone en JSON).

Este proyecto recibe, sin modificar ni una línea de comportamiento, las clases construidas en los Módulos 2 a 4 y las políticas de sanción del Módulo 8:

Trasladar estas clases a un proyecto propio es, en sí mismo, un ejemplo de "extraer clase" a mayor escala (08-05, apartado 4): el dominio queda físicamente separado de cualquier detalle de persistencia o de infraestructura web, algo que antes solo se conseguía con disciplina dentro de un único proyecto y ahora lo impone la propia estructura de la solución.

Este proyecto recibe, igualmente sin cambios de comportamiento, la interfaz y las cuatro clases construidas en 08-03:

La Lección 2 decidió Entity Framework Core como mecanismo de persistencia de producción; las otras tres implementaciones no se eliminan, simplemente no se registran en el contenedor de DI de BiblioTech.Api (apartado 4). Siguen disponibles, por ejemplo, para pruebas manuales rápidas sin base de datos, tal como ya se vio en 08-03, apartado 7.

Con la estructura de proyectos ya en su sitio, el registro de servicios en Program.cs es prácticamente el mismo que se construyó en 08-03, apartado 7, ahora con el resto de endpoints del apartado 5 añadidos:

Nótese la diferencia deliberada frente al builder.Configuration.GetConnectionString(...) de 07-03, donde la cadena de conexión estaba escrita directamente en el código: aquí se lee de la configuración (appsettings.json), un adelanto de la configuración por entorno que se completará en la Lección 5, y una aplicación directa del requisito no funcional de seguridad básica de la Lección 2 (no dejar cadenas de conexión de producción escritas en el código fuente).

Cada endpoint corresponde, de forma directa, a uno de los siete requisitos funcionales (RF1-RF7) de la Lección 2:

Uniendo todas las piezas anteriores, así queda el Program.cs completo de BiblioTech.Api:

Ningún endpoint contiene lógica de negocio propia: cada uno se limita a extraer datos de la petición HTTP (el mismo mecanismo de binding de 07-03), llamar a un método ya existente de Biblioteca o de sus dependencias, y traducir el resultado a una respuesta HTTP con Results.Ok/Results.NotFound/Results.Conflict. Esa es, precisamente, la señal de que la arquitectura desacoplada del Módulo 8 funcionó como se esperaba: la API es una capa fina sobre un dominio que ya sabía hacer todo esto desde mucho antes.

Este Program.cs, aunque nuevo como fichero, no introduce ninguna práctica que no se haya visto ya en el curso:

• Inyección por constructor/parámetro (08-03): cada endpoint recibe Biblioteca, IPoliticaSancion o IRepositorioBiblioteca ya resueltos por el contenedor, nunca los crea con new.
• Strategy (08-02): IPoliticaSancion permite cambiar de SancionFija a SancionProgresiva con una única línea en el registro de servicios, sin tocar el endpoint de devolución.
• Manejo de excepciones como control de flujo esperado (Módulo 2, 08-05): el try/catch sobre InvalidOperationException en POST /prestamos traduce un error de dominio esperado (libro no disponible) a un código HTTP concreto (409 Conflict), en vez de dejar que se propague como un error 500 genérico.
• Nomenclatura consistente (08-01): SolicitudPrestamo, AgregarMaterial, GuardarCatalogo siguen exactamente las mismas convenciones ya establecidas en la Lección 1 del Módulo 8.

• Referenciar BiblioTech.Api desde BiblioTech.Dominio: invertiría la dirección de dependencia del diagrama del apartado 1; el dominio nunca debe conocer la existencia de la capa web que lo consume.
• Registrar IPoliticaSancion como AddScoped en vez de AddSingleton: SancionFija no guarda ningún estado propio entre llamadas (apartado 4 de 08-03), así que puede compartirse de forma segura durante toda la vida de la aplicación; usar un ciclo de vida más corto del necesario no es incorrecto, pero desperdicia el motivo de ser de AddSingleton.
• Escribir lógica de negocio directamente dentro de un endpoint (por ejemplo, calcular la sanción a mano en vez de llamar a prestamo.CalcularSancion(politica)): duplicaría lógica que ya existe y ya está probada (Módulo 8, Lección 4), rompiendo la ventaja principal de reutilizar el dominio existente.
• Consejo: si un endpoint empieza a superar 4-5 líneas de lógica propia (sin contar la extracción de parámetros ni la traducción a Results.*), es una señal de "método largo" (08-05) a nivel de endpoint: probablemente falta extraer ese fragmento a un método de Biblioteca.

1. Añade un endpoint GET /socios/{id} que devuelva los datos de un socio concreto usando biblioteca.BuscarSocioPorId(id), devolviendo 404 Not Found si no existe.

2. El endpoint POST /prestamos/{id}/devolucion del apartado 6 usa biblioteca.Prestamos.ElementAtOrDefault(id) para localizar el préstamo por posición en la lista. Explica por qué esto es frágil en un sistema real, y qué cambiarías en el modelo de Prestamo para resolverlo de forma más robusta.

app.MapGet("/socios/{id}", (int id, Biblioteca biblioteca) =>
{
    Socio? socio = biblioteca.BuscarSocioPorId(id);

    return socio is not null
        ? Results.Ok(socio)
        : Results.NotFound($"No existe ningun socio con Id {id}.");
});

Usar la posición dentro de biblioteca.Prestamos como si fuera un identificador es frágil porque esa posición cambia si se elimina algún préstamo de la lista, o si el orden de inserción varía (por ejemplo, al recargar el catálogo desde el repositorio); dos peticiones distintas podrían referirse, sin darse cuenta, a préstamos distintos. La solución robusta es añadir una propiedad Id propia a Prestamo (siguiendo el mismo patrón que ya tiene Socio.Id, Módulo 3), asignada de forma única al crear cada préstamo, y buscar por ese Id en vez de por posición.

Esta lección ha ensamblado la Iteración 2 completa del proyecto: una estructura de solución con varios proyectos .NET con responsabilidades separadas, el registro de IRepositorioBiblioteca y Biblioteca en el contenedor de DI de ASP.NET Core retomando 07-03 y 08-03, y un Program.cs completo con un endpoint por cada uno de los siete requisitos funcionales de la Lección 2, sin ninguna lógica de negocio nueva que no existiera ya en el dominio de BiblioTech. La API funciona, pero todavía no se ha verificado con pruebas más allá de las unitarias del Módulo 8, ni se ha revisado con ningún criterio de calidad formal. La siguiente lección, Pruebas y Depuración, completa ese trabajo: amplía la batería de pruebas con pruebas de integración sobre estos mismos endpoints, e introduce el checklist de calidad que debe superarse antes de pasar a la Lección 5, Despliegue.