Ocho módulos han ido construyendo, pieza a pieza, un sistema completo de gestión de biblioteca llamado BiblioTech: desde el primer "Hola Mundo" y las variables del Módulo 1, pasando por el modelo de dominio orientado a objetos (MaterialBibliotecario, Libro, Revista, Socio, Prestamo) del Módulo 3, las interfaces, genéricos, colecciones, LINQ y programación asíncrona del Módulo 4, cuatro mecanismos de persistencia distintos del Módulo 5, reflexión y concurrencia del Módulo 6, cinco tecnologías de interfaz de usuario del Módulo 7, y finalmente las prácticas profesionales de diseño, inyección de dependencias, pruebas y refactorización del Módulo 8. Este último módulo no añade una pieza más al catálogo de técnicas: ensambla todas las piezas anteriores en una única aplicación completa, coherente y desplegable. Esta primera lección presenta el alcance exacto de ese proyecto final, las decisiones de arquitectura que se tomarán (y por qué), y los objetivos de aprendizaje que persigue.

1. Qué significa "proyecto final" en este curso
2. Elección de arquitectura: API + cliente frente a aplicación de escritorio
3. Piezas ya construidas que el proyecto reutiliza tal cual
4. Alcance funcional del proyecto
5. Objetivos de aprendizaje del Módulo 9

Un error común al pensar en un "proyecto final" es imaginar que hay que empezar de cero, con una idea nueva y ambiciosa que demuestre todo lo aprendido de una vez. Ese no es el enfoque de este módulo. BiblioTech ya existe: tiene un dominio maduro, varias formas de persistir sus datos, varias interfaces de usuario construidas a lo largo del Módulo 7, una arquitectura desacoplada mediante IRepositorioBiblioteca (Módulo 8), y una batería de pruebas unitarias que verifican su comportamiento. Lo que falta es unir esas piezas en una única aplicación coherente, tomando decisiones concretas allí donde el curso, hasta ahora, mostró alternativas por separado (texto, JSON, SQLite o Entity Framework para persistir; Windows Forms, WPF, ASP.NET Core, Blazor o MAUI para la interfaz).

Un proyecto final que reutiliza deliberadamente el trabajo de todo el curso, en vez de partir de cero, refleja además cómo funciona el desarrollo de software real: rara vez se empieza un proyecto sin ningún código, patrón o decisión previa; casi siempre se trata de ensamblar y completar piezas ya conocidas de una forma nueva y concreta.

El Módulo 7 mostró cinco formas distintas de dar interfaz a BiblioTech, cada una válida según el contexto. Para este proyecto final hay que elegir una combinación concreta, y esta lección recomienda la siguiente:

Esta lección y las cuatro siguientes desarrollan la primera opción —ASP.NET Core Minimal API como backend, con un cliente sencillo que la consuma (un cliente Blazor, o incluso una consola que use HttpClient, como la del Módulo 5)— por ser la combinación más moderna y relevante profesionalmente hoy en día. Se insiste, no obstante, en un punto importante: las alternativas de escritorio o móvil son igual de válidas. Si prefieres construir el proyecto final con Windows Forms, WPF o MAUI en vez de una API web, todo el resto de este módulo —requisitos, planificación, pruebas, checklist de calidad, incluso buena parte del despliegue con dotnet publish— se aplica exactamente igual; solo cambiaría la lección de Implementación, donde en vez de Program.cs de una API tendrías el Form/Window/página XAML correspondiente consumiendo directamente Biblioteca con IRepositorioBiblioteca inyectado, tal como ya viste en las lecciones de Windows Forms, WPF y MAUI del Módulo 7.

Una diferencia de diseño importante frente al Módulo 7 merece explicarse ya: la lección de Blazor inyectaba Biblioteca directamente como servicio dentro del propio proceso Blazor Server, sin pasar por HTTP. En este proyecto final, en cambio, Biblioteca vive solo dentro de la API, y cualquier cliente —incluido un cliente Blazor— la consume exclusivamente a través de sus endpoints HTTP. Es una decisión deliberada: así, la misma API puede servir a la vez a un cliente Blazor, a una futura app MAUI, o a cualquier otro consumidor, sin que ninguno necesite acceso directo al proceso ni a la base de datos.

Nada de lo siguiente se reescribe desde cero; el proyecto final las retoma exactamente como quedaron:

• Dominio (Módulos 2-3): MaterialBibliotecario (clase abstracta), Libro y Revista como sus dos implementaciones, Socio, Prestamo con CalcularSancion(IPoliticaSancion).
• Interfaces y patrones de comportamiento (Módulo 4, Módulo 8): IPrestable, IBuscable, IPoliticaSancion con SancionFija y SancionProgresiva (patrón Strategy).
• La clase Biblioteca (Módulo 4): Catalogo, Socios, Prestamos, el evento PrestamoRegistrado, PrestarLibroAsync, ObtenerMetadatosPorIsbnAsync (Módulo 5, consulta a un servicio externo por ISBN).
• IRepositorioBiblioteca (Módulo 8) y sus cuatro implementaciones: RepositorioTexto, RepositorioJson, RepositorioSqlite, RepositorioEntityFramework (con BibliotecaDbContext del Módulo 5).
• La batería de pruebas xUnit + Moq (Módulo 8) sobre Prestamo.RegistrarDevolucion() y Biblioteca.PrestarLibroAsync.
• Los estándares de codificación y el resultado de la refactorización (Módulo 8): nomenclatura consistente, GestionarPrestamoAsync ya dividido en ValidarPrestamo y RegistrarYPersistirPrestamo.

El proyecto final de BiblioTech debe cubrir, como mínimo, las siguientes capacidades —todas ellas construidas ya en módulos anteriores, ahora expuestas de forma unificada:

Ninguna de estas capacidades es nueva: el trabajo de este módulo consiste en exponerlas todas juntas, de forma coherente, a través de una única API, en vez de tenerlas dispersas en ejemplos sueltos de lecciones distintas.

Al completar este módulo, habrás:

• Definido requisitos funcionales y no funcionales concretos para una aplicación real (Lección 2).
• Planificado el trabajo en iteraciones pequeñas, en vez de intentar construirlo todo de golpe (Lección 2).
• Ensamblado una solución con varios proyectos .NET relacionados, registrando las dependencias del Módulo 8 en el contenedor de DI de una API real (Lección 3).
• Ampliado la batería de pruebas con pruebas de integración, y aplicado técnicas de depuración y logging en un contexto realista (Lección 4).
• Publicado y contenedorizado una aplicación .NET, con configuración distinta por entorno (Lección 5).

• Querer añadir funcionalidad nueva "porque sería interesante": el objetivo de este módulo es ensamblar y pulir lo ya construido, no ampliar el dominio de BiblioTech; cualquier idea nueva puede anotarse para "después de terminar el curso", pero no debería retrasar el cierre del proyecto.
• Descartar las alternativas de escritorio o móvil como "peores": no lo son; la elección de ASP.NET Core + cliente en este módulo responde a relevancia laboral actual y a la posibilidad de mostrar varios clientes distintos consumiendo la misma lógica, no a que Windows Forms, WPF o MAUI sean opciones inferiores.
• Empezar a programar antes de leer la Lección 2 (Requisitos y Planificación): sin una lista clara de requisitos y una planificación en fases, es fácil perderse ensamblando piezas en el orden equivocado.
• Consejo: antes de escribir una sola línea de código de este proyecto, relee brevemente 08-03 (IRepositorioBiblioteca), 08-04 (pruebas) y 08-05 (refactorización); son, literalmente, el punto de partida exacto de la Lección 3 de este módulo.

1. Sin mirar todavía la Lección 2, escribe tu propia lista de 5 casos de uso que crees que debe cubrir el proyecto final de BiblioTech, basándote solo en el alcance funcional del apartado 4.

2. Explica, en dos o tres frases, por qué la arquitectura con IRepositorioBiblioteca del Módulo 8 hace que la elección de "qué mecanismo de persistencia usar en producción" (apartado 3) sea una decisión de bajo riesgo, fácil de cambiar más adelante si hiciera falta.

Una lista razonable (la tuya puede variar en la redacción, pero debería cubrir ideas equivalentes): (1) dar de alta un libro o revista nuevo en el catálogo; (2) buscar materiales por título o autor; (3) dar de alta un socio nuevo; (4) registrar un préstamo de un material disponible; (5) registrar la devolución de un préstamo, calculando la sanción si hay retraso.

Como Biblioteca depende únicamente de la interfaz IRepositorioBiblioteca (Módulo 8) y no de ninguna implementación concreta, cambiar el mecanismo de persistencia en producción —por ejemplo, de SQLite a Entity Framework Core, o viceversa— no requiere modificar Biblioteca ni ningún endpoint que la use: basta con registrar una implementación distinta de IRepositorioBiblioteca en el contenedor de DI (como se vio en 08-03, apartado 7). El riesgo de esa decisión queda así contenido en un único punto del programa.

Esta lección ha presentado el proyecto final de BiblioTech como lo que realmente es: la culminación de ocho módulos de trabajo, no un proyecto nuevo. Has visto la arquitectura elegida (ASP.NET Core Minimal API con un cliente que la consuma por HTTP, dejando claro que escritorio o móvil son alternativas igual de válidas), qué piezas concretas de módulos anteriores se reutilizan tal cual, el alcance funcional exacto que debe cubrir el proyecto, y los objetivos de aprendizaje de este módulo. Con esta visión de conjunto ya clara, la siguiente lección, Requisitos y Planificación, convierte ese alcance en una lista concreta de requisitos y en un plan de trabajo por iteraciones, el paso imprescindible antes de escribir la primera línea de código del proyecto.