Amb els requisits i la planificació de la lliçó anterior ja tancats, aquesta lliçó ensambla la Iteració 2 completa: l'API de BiblioTech. No s'escriu lògica de domini nova —tot el comportament ja existeix a Biblioteca, a IRepositoriBiblioteca i a les seves implementacions—; la feina consisteix a organitzar aquest codi en una estructura de solució amb diversos projectes, registrar correctament les dependències al contenidor de DI d'ASP.NET Core (recuperant 07-03 i 08-03), i exposar un endpoint per cadascun dels set requisits funcionals definits a la Lliçó 2.

1. Estructura de la solució: diversos projectes .NET
2. BiblioTech.Domini: el model ja construït, sense canvis
3. BiblioTech.Persistencia: IRepositoriBiblioteca i les seves quatre implementacions
4. BiblioTech.Api: registrant serveis al contenidor de DI
5. Endpoints: catàleg, socis, préstecs, devolucions, metadades
6. Program.cs complet
7. Aplicant patrons i estàndards ja vistos

Fins ara, cada lliçó del curs treballava amb un únic projecte de consola o un únic projecte de la tecnologia de torn. Un projecte real d'aquesta mida s'organitza millor en diversos projectes .NET separats, agrupats en una solució (.sln), cadascun amb una responsabilitat pròpia —el mateix principi de responsabilitat única de 08-01, aplicat ara a nivell de projecte en comptes de a nivell de classe:

Les fletxes del diagrama són direccions de dependència (dotnet add reference): Domini no depèn de cap altre projecte —ni tan sols sap que existeix persistència o una API—, mentre que Persistencia i Api depenen d'ell. Aquesta direcció no és casualitat: és exactament el mateix principi que va motivar extreure IRepositoriBiblioteca a 08-03, ara aplicat a l'organització de carpetes i projectes, no només a les classes dins d'un únic projecte. Un projecte opcional BiblioTech.Web (un client Blazor) es tractaria exactament igual: dependria només del que fos estrictament necessari per consumir l'API per HTTP, sense referenciar directament BiblioTech.Domini ni BiblioTech.Persistencia (el client no coneix aquestes classes: només coneix els DTO que l'API exposa en JSON).

Aquest projecte rep, sense modificar-hi ni una línia de comportament, les classes construïdes als Mòduls 2 a 4 i les polítiques de sanció del Mòdul 8:

Traslladar aquestes classes a un projecte propi és, en si mateix, un exemple d'"extreure classe" a gran escala (08-05, apartat 4): el domini queda físicament separat de qualsevol detall de persistència o d'infraestructura web, quelcom que abans només s'aconseguia amb disciplina dins d'un únic projecte i ara ho imposa la mateixa estructura de la solució.

Aquest projecte rep, igualment sense canvis de comportament, la interfície i les quatre classes construïdes a 08-03:

La Lliçó 2 va decidir Entity Framework Core com a mecanisme de persistència de producció; les altres tres implementacions no s'eliminen, simplement no es registren al contenidor de DI de BiblioTech.Api (apartat 4). Segueixen disponibles, per exemple, per a proves manuals ràpides sense base de dades, tal com ja es va veure a 08-03, apartat 7.

Amb l'estructura de projectes ja al seu lloc, el registre de serveis a Program.cs és pràcticament el mateix que es va construir a 08-03, apartat 7, ara amb la resta d'endpoints de l'apartat 5 afegits:

Cal notar la diferència deliberada respecte al builder.Configuration.GetConnectionString(...) de 07-03, on la cadena de connexió estava escrita directament al codi: aquí es llegeix de la configuració (appsettings.json), un avançament de la configuració per entorn que es completarà a la Lliçó 5, i una aplicació directa del requisit no funcional de seguretat bàsica de la Lliçó 2 (no deixar cadenes de connexió de producció escrites al codi font).

Cada endpoint correspon, de forma directa, a un dels set requisits funcionals (RF1-RF7) de la Lliçó 2:

Unint totes les peces anteriors, així queda el Program.cs complet de BiblioTech.Api:

Cap endpoint conté lògica de negoci pròpia: cadascun es limita a extreure dades de la petició HTTP (el mateix mecanisme de binding de 07-03), cridar un mètode ja existent de Biblioteca o de les seves dependències, i traduir el resultat a una resposta HTTP amb Results.Ok/Results.NotFound/Results.Conflict. Aquest és, precisament, el senyal que l'arquitectura desacoblada del Mòdul 8 ha funcionat com s'esperava: l'API és una capa fina sobre un domini que ja sabia fer tot això des de molt abans.

Aquest Program.cs, encara que nou com a fitxer, no introdueix cap pràctica que no s'hagi vist ja al curs:

• Injecció per constructor/paràmetre (08-03): cada endpoint rep Biblioteca, IPoliticaSancio o IRepositoriBiblioteca ja resolts pel contenidor, mai els crea amb new.
• Strategy (08-02): IPoliticaSancio permet canviar de SancioFixa a SancioProgressiva amb una única línia al registre de serveis, sense tocar l'endpoint de devolució.
• Gestió d'excepcions com a control de flux esperat (Mòdul 2, 08-05): el try/catch sobre InvalidOperationException a POST /prestamos tradueix un error de domini esperat (llibre no disponible) a un codi HTTP concret (409 Conflict), en comptes de deixar que es propagui com un error 500 genèric.
• Nomenclatura consistent (08-01): PeticioPrestec, AfegirMaterial, GuardarCataleg segueixen exactament les mateixes convencions ja establertes a la Lliçó 1 del Mòdul 8.

• Referenciar BiblioTech.Api des de BiblioTech.Domini: invertiria la direcció de dependència del diagrama de l'apartat 1; el domini mai ha de conèixer l'existència de la capa web que el consumeix.
• Registrar IPoliticaSancio com a AddScoped en comptes de AddSingleton: SancioFixa no desa cap estat propi entre crides (apartat 4 de 08-03), així que es pot compartir de forma segura durant tota la vida de l'aplicació; fer servir un cicle de vida més curt del necessari no és incorrecte, però malbarata el motiu de ser de AddSingleton.
• Escriure lògica de negoci directament dins d'un endpoint (per exemple, calcular la sanció a mà en comptes de cridar prestec.CalcularSancio(politica)): duplicaria lògica que ja existeix i ja està provada (Mòdul 8, Lliçó 4), trencant l'avantatge principal de reutilitzar el domini existent.
• Consell: si un endpoint comença a superar 4-5 línies de lògica pròpia (sense comptar l'extracció de paràmetres ni la traducció a Results.*), és un senyal de "mètode llarg" (08-05) a nivell d'endpoint: probablement falta extreure aquest fragment a un mètode de Biblioteca.

1. Afegeix un endpoint GET /socios/{id} que retorni les dades d'un soci concret fent servir biblioteca.CercarSociPerId(id), retornant 404 Not Found si no existeix.

2. L'endpoint POST /prestamos/{id}/devolucion de l'apartat 6 fa servir biblioteca.Prestecs.ElementAtOrDefault(id) per localitzar el préstec per posició a la llista. Explica per què això és fràgil en un sistema real, i què canviaries al model de Prestec per resoldre-ho de forma més robusta.

app.MapGet("/socios/{id}", (int id, Biblioteca biblioteca) =>
{
    Soci? soci = biblioteca.CercarSociPerId(id);

    return soci is not null
        ? Results.Ok(soci)
        : Results.NotFound($"No existeix cap soci amb Id {id}.");
});

Fer servir la posició dins de biblioteca.Prestecs com si fos un identificador és fràgil perquè aquesta posició canvia si s'elimina algun préstec de la llista, o si l'ordre d'inserció varia (per exemple, en recarregar el catàleg des del repositori); dues peticions diferents podrien referir-se, sense adonar-se'n, a préstecs diferents. La solució robusta és afegir una propietat Id pròpia a Prestec (seguint el mateix patró que ja té Soci.Id, Mòdul 3), assignada de forma única en crear cada préstec, i cercar per aquest Id en comptes de per posició.

Aquesta lliçó ha ensamblat la Iteració 2 completa del projecte: una estructura de solució amb diversos projectes .NET amb responsabilitats separades, el registre d'IRepositoriBiblioteca i Biblioteca al contenidor de DI d'ASP.NET Core recuperant 07-03 i 08-03, i un Program.cs complet amb un endpoint per cadascun dels set requisits funcionals de la Lliçó 2, sense cap lògica de negoci nova que no existís ja al domini de BiblioTech. L'API funciona, però encara no s'ha verificat amb proves més enllà de les unitàries del Mòdul 8, ni s'ha revisat amb cap criteri de qualitat formal. La lliçó següent, Proves i Depuració, completa aquesta feina: amplia la bateria de proves amb proves d'integració sobre aquests mateixos endpoints, i introdueix el checklist de qualitat que ha de superar-se abans de passar a la Lliçó 5, Desplegament.