Vuit mòduls han anat construint, peça a peça, un sistema complet de gestió de biblioteca anomenat BiblioTech: des del primer "Hola Món" i les variables del Mòdul 1, passant pel model de domini orientat a objectes (MaterialBibliotecari, Llibre, Revista, Soci, Prestec) del Mòdul 3, les interfícies, genèrics, col·leccions, LINQ i programació asíncrona del Mòdul 4, quatre mecanismes de persistència diferents del Mòdul 5, reflexió i concurrència del Mòdul 6, cinc tecnologies d'interfície d'usuari del Mòdul 7, i finalment les pràctiques professionals de disseny, injecció de dependències, proves i refactorització del Mòdul 8. Aquest últim mòdul no afegeix una peça més al catàleg de tècniques: ensambla totes les peces anteriors en una única aplicació completa, coherent i desplegable. Aquesta primera lliçó presenta l'abast exacte d'aquest projecte final, les decisions d'arquitectura que es prendran (i per què), i els objectius d'aprenentatge que persegueix.

1. Què significa "projecte final" en aquest curs
2. Elecció d'arquitectura: API + client enfront d'aplicació d'escriptori
3. Peces ja construïdes que el projecte reutilitza tal qual
4. Abast funcional del projecte
5. Objectius d'aprenentatge del Mòdul 9

Un error habitual en pensar en un "projecte final" és imaginar que cal començar de zero, amb una idea nova i ambiciosa que demostri tot l'après d'una sola vegada. Aquest no és l'enfocament d'aquest mòdul. BiblioTech ja existeix: té un domini madur, diverses formes de persistir les seves dades, diverses interfícies d'usuari construïdes al llarg del Mòdul 7, una arquitectura desacoblada mitjançant IRepositoriBiblioteca (Mòdul 8), i una bateria de proves unitàries que verifiquen el seu comportament. El que falta és unir aquestes peces en una única aplicació coherent, prenent decisions concretes allà on el curs, fins ara, va mostrar alternatives per separat (text, JSON, SQLite o Entity Framework per persistir; Windows Forms, WPF, ASP.NET Core, Blazor o MAUI per a la interfície).

Un projecte final que reutilitza deliberadament la feina de tot el curs, en comptes de partir de zero, reflecteix a més com funciona el desenvolupament de programari real: rara vegada es comença un projecte sense cap codi, patró o decisió prèvia; gairebé sempre es tracta d'ensamblar i completar peces ja conegudes d'una forma nova i concreta.

El Mòdul 7 va mostrar cinc formes diferents de donar interfície a BiblioTech, cadascuna vàlida segons el context. Per a aquest projecte final cal triar una combinació concreta, i aquesta lliçó recomana la següent:

Aquesta lliçó i les quatre següents desenvolupen la primera opció —ASP.NET Core Minimal API com a backend, amb un client senzill que la consumeixi (un client Blazor, o fins i tot una consola que faci servir HttpClient, com la del Mòdul 5)— per ser la combinació més moderna i rellevant professionalment avui dia. S'insisteix, no obstant això, en un punt important: les alternatives d'escriptori o mòbil són igual de vàlides. Si prefereixes construir el projecte final amb Windows Forms, WPF o MAUI en comptes d'una API web, tota la resta d'aquest mòdul —requisits, planificació, proves, checklist de qualitat, fins i tot bona part del desplegament amb dotnet publish— s'aplica exactament igual; només canviaria la lliçó d'Implementació, on en comptes del Program.cs d'una API tindries el Form/Window/pàgina XAML corresponent consumint directament Biblioteca amb IRepositoriBiblioteca injectat, tal com ja vas veure a les lliçons de Windows Forms, WPF i MAUI del Mòdul 7.

Una diferència de disseny important respecte al Mòdul 7 val la pena explicar-la ja: la lliçó de Blazor injectava Biblioteca directament com a servei dins del propi procés Blazor Server, sense passar per HTTP. En aquest projecte final, en canvi, Biblioteca viu només dins de l'API, i qualsevol client —inclòs un client Blazor— la consumeix exclusivament a través dels seus endpoints HTTP. És una decisió deliberada: així, la mateixa API pot servir alhora un client Blazor, una futura app MAUI, o qualsevol altre consumidor, sense que cap necessiti accés directe al procés ni a la base de dades.

Res del que segueix es reescriu des de zero; el projecte final ho recupera exactament tal com va quedar:

• Domini (Mòduls 2-3): MaterialBibliotecari (classe abstracta), Llibre i Revista com les seves dues implementacions, Soci, Prestec amb CalcularSancio(IPoliticaSancio).
• Interfícies i patrons de comportament (Mòdul 4, Mòdul 8): IPrestable, ICercable, IPoliticaSancio amb SancioFixa i SancioProgressiva (patró Strategy).
• La classe Biblioteca (Mòdul 4): Cataleg, Socis, Prestecs, l'esdeveniment PrestecRegistrat, PrestarLlibreAsync, ObtenirMetadadesPerIsbnAsync (Mòdul 5, consulta a un servei extern per ISBN).
• IRepositoriBiblioteca (Mòdul 8) i les seves quatre implementacions: RepositoriText, RepositoriJson, RepositoriSqlite, RepositoriEntityFramework (amb BibliotecaDbContext del Mòdul 5).
• La bateria de proves xUnit + Moq (Mòdul 8) sobre Prestec.RegistrarDevolucio() i Biblioteca.PrestarLlibreAsync.
• Els estàndards de codificació i el resultat de la refactorització (Mòdul 8): nomenclatura consistent, GestionarPrestecAsync ja dividit en ValidarPrestec i RegistrarIPersistirPrestec.

El projecte final de BiblioTech ha de cobrir, com a mínim, les següents capacitats —totes ja construïdes en mòduls anteriors, ara exposades de forma unificada:

Cap d'aquestes capacitats és nova: la feina d'aquest mòdul consisteix a exposar-les totes juntes, de forma coherent, a través d'una única API, en comptes de tenir-les disperses en exemples solts de lliçons diferents.

En completar aquest mòdul, hauràs:

• Definit requisits funcionals i no funcionals concrets per a una aplicació real (Lliçó 2).
• Planificat la feina en iteracions petites, en comptes d'intentar construir-ho tot de cop (Lliçó 2).
• Ensamblat una solució amb diversos projectes .NET relacionats, registrant les dependències del Mòdul 8 al contenidor de DI d'una API real (Lliçó 3).
• Ampliat la bateria de proves amb proves d'integració, i aplicat tècniques de depuració i logging en un context realista (Lliçó 4).
• Publicat i contenidoritzat una aplicació .NET, amb configuració diferent per entorn (Lliçó 5).

• Voler afegir funcionalitat nova "perquè seria interessant": l'objectiu d'aquest mòdul és ensamblar i polir el que ja està construït, no ampliar el domini de BiblioTech; qualsevol idea nova es pot anotar per a "després d'acabar el curs", però no hauria de retardar el tancament del projecte.
• Descartar les alternatives d'escriptori o mòbil com a "pitjors": no ho són; l'elecció d'ASP.NET Core + client en aquest mòdul respon a la rellevància laboral actual i a la possibilitat de mostrar diversos clients diferents consumint la mateixa lògica, no al fet que Windows Forms, WPF o MAUI siguin opcions inferiors.
• Començar a programar abans de llegir la Lliçó 2 (Requisits i Planificació): sense una llista clara de requisits i una planificació en fases, és fàcil perdre's ensamblant peces en l'ordre equivocat.
• Consell: abans d'escriure una sola línia de codi d'aquest projecte, rellegeix breument 08-03 (IRepositoriBiblioteca), 08-04 (proves) i 08-05 (refactorització); són, literalment, el punt de partida exacte de la Lliçó 3 d'aquest mòdul.

1. Sense mirar encara la Lliçó 2, escriu la teva pròpia llista de 5 casos d'ús que creguis que ha de cobrir el projecte final de BiblioTech, basant-te només en l'abast funcional de l'apartat 4.

2. Explica, en dues o tres frases, per què l'arquitectura amb IRepositoriBiblioteca del Mòdul 8 fa que l'elecció de "quin mecanisme de persistència fer servir en producció" (apartat 3) sigui una decisió de baix risc, fàcil de canviar més endavant si calgués.

Una llista raonable (la teva pot variar en la redacció, però hauria de cobrir idees equivalents): (1) donar d'alta un llibre o revista nova al catàleg; (2) cercar materials per títol o autor; (3) donar d'alta un soci nou; (4) registrar un préstec d'un material disponible; (5) registrar la devolució d'un préstec, calculant la sanció si hi ha retard.

Com que Biblioteca depèn únicament de la interfície IRepositoriBiblioteca (Mòdul 8) i no de cap implementació concreta, canviar el mecanisme de persistència en producció —per exemple, de SQLite a Entity Framework Core, o viceversa— no requereix modificar Biblioteca ni cap endpoint que la faci servir: n'hi ha prou de registrar una implementació diferent d'IRepositoriBiblioteca al contenidor de DI (com es va veure a 08-03, apartat 7). El risc d'aquesta decisió queda així contingut en un únic punt del programa.

Aquesta lliçó ha presentat el projecte final de BiblioTech com el que realment és: la culminació de vuit mòduls de feina, no un projecte nou. Has vist l'arquitectura triada (ASP.NET Core Minimal API amb un client que la consumeixi per HTTP, deixant clar que escriptori o mòbil són alternatives igual de vàlides), quines peces concretes de mòduls anteriors es reutilitzen tal qual, l'abast funcional exacte que ha de cobrir el projecte, i els objectius d'aprenentatge d'aquest mòdul. Amb aquesta visió de conjunt ja clara, la lliçó següent, Requisits i Planificació, converteix aquest abast en una llista concreta de requisits i en un pla de treball per iteracions, el pas imprescindible abans d'escriure la primera línia de codi del projecte.