Arribem al final del curs, i res consolida millor el que hem après que dissenyar un sistema complet des de zero aplicant, de forma justificada, les decisions que hem anat estudiant. En aquesta lliçó actuarem com l'equip d'arquitectura d'una empresa fictícia, MercadoFiatc, que necessita construir una plataforma de comerç electrònic. Partirem dels requisits de negoci, els traduirem en atributs de qualitat, triarem un estil arquitectònic amb la seva justificació, modelarem les dades, definirem desplegament i observabilitat, i registrarem les decisions clau com a ADR. No busquem "la" resposta correcta —en arquitectura gairebé mai no existeix—, sinó mostrar un raonament coherent: cada decisió es deriva d'un requisit i assumeix conscientment els seus compromisos. Aquest cas tanca el curs integrant els mòduls sobre estils, dades, comunicació, desplegament, governança i evolució.

1. Requisits de MercadoFiatc
2. De requisits a atributs de qualitat
3. Elecció de l'estil arquitectònic
4. Diagrama C4 del sistema
5. Disseny de dades
6. Comunicació entre components
7. Desplegament
8. Observabilitat
9. Decisions registrades (ADR) i evolució
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió del curs

El negoci ens planteja aquests requisits funcionals i restriccions:

• Catàleg de productes navegable i amb cerca, desenes de milers de referències.
• Cistella de la compra i procés de pagament (checkout) amb passarel·la externa.
• Gestió de comandes i el seu estat (confirmat, preparant, enviat, lliurat).
• Recomanacions de productes.
• Pics de trànsit molt forts en campanyes (Black Friday): la navegació del catàleg es pot multiplicar per 50, mentre que pagaments creix molt menys.
• Equip d'unes 25 persones, organitzat en 4 squads.
• Pressupost operatiu limitat: no es vol pagar la complexitat del distribuït on no aporti.

El primer pas de qualsevol arquitectura seriosa és traduir requisits de negoci en atributs de qualitat mesurables, perquè són ells —i no les funcionalitats— els que més condicionen el disseny.

Observa la tensió clau: necessitem escalat granular (catàleg creix molt més que pagaments) i autonomia de squads, cosa que empeny cap a microserveis; però el cost operatiu limitat i la consistència de la comanda empenyen cap al monòlit. L'arquitectura naixerà d'equilibrar aquestes forces.

No saltem directament a "microserveis per a tot". Avaluem opcions:

Triem l'enfocament mixt i evolutiu, totalment alineat amb el que hem après: comencem amb un monòlit modular ben delimitat per dominis (Catàleg, Cistella, Comandes, Pagaments, Recomanacions) i extraiem com a microservei només allò que tingui necessitats d'escalat o disponibilitat dispars. En concret:

• Catàleg s'extreu aviat: és el que pateix el x50 en campanya i convé escalar-lo sol.
• Recomanacions s'extreu: és opcional, pot fallar sense trencar la compra i evoluciona ràpid.
• Cistella, Comandes i Pagaments romanen junts al monòlit modular al principi, perquè comparteixen transaccions i consistència forta; extreure'ls aviat portaria sagues i dolor sense benefici clar.

Aquesta decisió aplica directament la regla MonolithFirst i el patró Strangler Fig: el monòlit modular és el punt de partida, i l'extracció és incremental i guiada per dolor real.

Fem servir el model C4 (Context, Contenidors, Components, Codi) per comunicar el disseny a diferents audiències. Mostrem el nivell de Contenidors, el més útil per a arquitectura.

Llegim el diagrama, que sintetitza gairebé totes les decisions:

• L'API Gateway actua també de Strangler Facade: enruta cada petició al servei extret o al monòlit. És el punt des del qual continuarem estrangulant si cal.
• Catàleg i Recomanacions són contenidors independents amb la seva pròpia base de dades: es poden escalar i desplegar per separat.
• El monòlit modular agrupa Cistella, Comandes i Pagaments sobre una única base de dades, permetent transaccions ACID locals en el checkout.
• La comunicació amb Recomanacions és asíncrona per esdeveniments (PedidoConfirmado via broker): així la comanda no depèn que Recomanacions estigui disponible.

Apliquem el principi una base de dades per servei on hi ha serveis separats, i consistència forta on la transacció ho exigeix:

La decisió més delicada és la consistència entre comanda i pagament. Com que viuen al mateix monòlit sobre la mateixa BD relacional, confirmar la comanda i registrar el pagament passa en una transacció ACID local: o es fa tot o res. Això evita les sagues distribuïdes, que només introduiríem si més endavant extraguéssim Pagaments. La relació amb Recomanacions, en canvi, és consistència eventual: després de confirmar la comanda es publica un esdeveniment i Recomanacions s'actualitza amb un petit retard, cosa perfectament acceptable per a dades suggerides.

Combinem estils de comunicació segons la naturalesa de cada interacció:

• Síncrona (REST/HTTP) a través del gateway per a les peticions del client: navegar catàleg, veure cistella, fer checkout. L'usuari espera resposta immediata.
• Asíncrona per esdeveniments per a integracions internes que toleren retard: PedidoConfirmado dispara l'actualització de Recomanacions i, en el futur, de Facturació.
• Anti-Corruption Layer al servei de Catàleg si calgués integrar-se amb un PIM (Product Information Management) heretat amb un model de dades antic.

Aquest contracte d'esdeveniment és la frontera pública entre el monòlit i els consumidors (Recomanacions avui, Facturació demà). Definir-lo de forma explícita i versionada (version: 1) és essencial: els consumidors depenen de la seva forma, així que un canvi incompatible exigiria una version: 2. L'esdeveniment porta només el necessari i no inclou dades personals sensibles més enllà d'identificadors, cosa que a més ajuda a respectar la minimització de dades.

El desplegament reflecteix l'arquitectura mixta i el pressupost contingut:

• Contenidors (Docker) orquestrats amb Kubernetes, però amb poques peces: monòlit, catàleg, recomanacions, gateway i broker. No multipliquem serveis sense necessitat.
• Escalat horitzontal independent: Catàleg es configura amb autoescalat agressiu (moltes rèpliques en campanya); el monòlit i els altres, amb un escalat més moderat.
• Desplegament independent per squad: cada contenidor té el seu propi pipeline, de manera que el squad de Catàleg desplega sense coordinar-se amb el de Comandes. Això satisfà l'atribut d'autonomia.
• Estratègia de desplegament progressiu (canary o blue-green) per reduir el risc en cada release, amb possibilitat de revertir.

Aquest manifest materialitza el requisit d'escalabilitat granular: el catàleg pot passar de 3 a 60 rèpliques automàticament quan la CPU supera el 65% d'ús, absorbint el pic de campanya, mentre la resta del sistema manté la seva capacitat habitual. És exactament el benefici que justificava extreure Catàleg com a servei a part.

Un sistema amb peces distribuïdes i esdeveniments asíncrons és opac sense observabilitat. Implementem els tres pilars:

• Logs estructurats (JSON) centralitzats, amb un traceId comú en totes les peces.
• Mètriques (Prometheus/Grafana): latència p95 per servei, taxa d'errors, profunditat de les cues del broker, rèpliques actives.
• Traces distribuïdes (OpenTelemetry): seguir una petició de checkout a través del gateway, el monòlit i el broker, veient on se'n va el temps.

L'observabilitat no és un luxe: és la condició prèvia per evolucionar amb seguretat. Sense mètriques de latència del catàleg, no sabríem si l'autoescalat funciona; sense traces, depurar el flux d'esdeveniments de Recomanacions seria endevinar. A més, les mètriques alimenten fitness functions contínues: una alerta si el p95 de checkout supera 300 ms és una funció d'aptitud que vigila la salut arquitectònica en producció.

Tanquem el disseny documentant les decisions clau com a ADR, tal com vam veure en la lliçó de governança:

• ADR-001: Començar amb monòlit modular i extreure serveis només per dolor (escalat/disponibilitat). Conseqüència: baix cost inicial; acceptem refactoritzar fronteres més tard.
• ADR-002: Extreure Catàleg com a servei independent. Conseqüència: escalat granular; cost d'una BD i un pipeline propis.
• ADR-003: Comunicació asíncrona per esdeveniments cap a Recomanacions. Conseqüència: desacoblament i disponibilitat; consistència eventual i idempotència obligatòria.
• ADR-004: Mantenir Cistella, Comandes i Pagaments junts amb transacció ACID local. Conseqüència: consistència forta sense sagues; reavaluar si Pagaments necessita escalar a part.

I protegim l'arquitectura amb fitness functions: tests d'ArchUnit que prohibeixen cicles entre els mòduls del monòlit i que impedeixen que el domini depengui de la infraestructura, més una fitness contínua de latència en producció. Així, l'arquitectura està documentada (ADR) i vigilada (fitness functions): pot evolucionar sense degradar-se. Quan un mòdul del monòlit comenci a fer mal, el Strangler Facade ja és al seu lloc per extreure'l de forma incremental.

• Començar per la solució i no pels atributs de qualitat. Dissenyar "amb microserveis" abans de saber què cal escalar és posar-se la resposta abans que la pregunta.
• Extreure serveis per moda. Cada servei extret costa operació, observabilitat i consistència. Extreu només on l'atribut de qualitat ho justifiqui (Catàleg sí, Pagaments encara no).
• Oblidar la consistència en separar. En el moment en què parteixes una transacció entre serveis, entres en sagues i consistència eventual. Tingues-ho clar abans de tallar.
• Dissenyar sense observabilitat. Un sistema mixt sense traces ni mètriques és impossible d'evolucionar amb seguretat.
• No documentar les decisions. Sense ADR, d'aquí a un any ningú no recordarà per què Pagaments és al monòlit i algú ho "arreglarà" creant un embolic.
• Consell: revisa que cada decisió del disseny es pugui traçar fins a un requisit o atribut de qualitat concret. Si no pots, probablement sobra.

Exercici 1. El negoci afegeix un requisit: "l'enviament d'emails transaccionals (confirmació de comanda) no ha de ralentir el checkout i ha de poder reintentar-se si el proveïdor d'email falla". Com ho integraries en l'arquitectura proposada?

Exercici 2. Al cap de sis mesos, les mètriques mostren que Pagaments pateix pics propis i l'equip vol desplegar-lo a part. Descriu, amb el que has après, com l'extrauries del monòlit i quin problema nou de consistència apareix.

Exercici 3. Justifica per què Catàleg fa servir un magatzem orientat a cerca i lectures, mentre que Comandes fa servir un relacional ACID. Relaciona cada elecció amb un atribut de qualitat.

Solució 1. Mitjançant comunicació asíncrona per esdeveniments: el checkout publica PedidoConfirmado (ja existeix) i un consumidor de notificacions envia l'email de forma diferida. Així el checkout no espera l'email; si el proveïdor falla, el consumidor reintenta des de la cua. Convé idempotència per no enviar el correu dos cops si l'esdeveniment es reentrega.

Solució 2. Aplicant Branch by Abstraction dins del monòlit (interfície ServicioPagos), després construint el microservei de Pagaments amb la seva pròpia BD i commutant amb feature flags via el gateway (Strangler). El problema nou: la confirmació de comanda i el registre de pagament deixen de compartir transacció ACID; apareix la necessitat d'una saga amb compensació (p. ex. cancel·lar la comanda si el pagament falla) i consistència eventual entre tots dos.

Solució 3. Catàleg prioritza rendiment i escalabilitat de lectura (cerca ràpida sobre desenes de milers de referències sota pics x50), d'aquí un magatzem optimitzat per a cerca i rèpliques. Comandes prioritza consistència: el checkout creua cistella, comanda i pagament en una operació que ha de ser tot-o-res, cosa que exigeix transaccions ACID d'un relacional.

Amb aquest estudi de cas tanquem el curs d'Arquitectura d'Aplicacions. Hem vist com un bon disseny no neix de triar la tecnologia de moda, sinó d'un raonament disciplinat: traduir requisits de negoci en atributs de qualitat mesurables, triar l'estil que millor els equilibra —a MercadoFiatc, un monòlit modular que evoluciona extraient només allò que ho justifica—, modelar les dades segons les necessitats de consistència, combinar comunicació síncrona i asíncrona, desplegar amb escalat granular on importa, i sostenir-ho tot amb observabilitat. I, sobretot, hem tancat el cercle del mòdul final: documentar les decisions amb ADR, protegir-les amb fitness functions i deixar preparat el Strangler Facade per continuar evolucionant de forma incremental i guiada.

Al llarg del curs has recorregut el camí complet: què és l'arquitectura, els estils monolítics i distribuïts, les capes i l'arquitectura hexagonal, la gestió de dades i la comunicació, el desplegament, i finalment l'evolució i la governança. La lliçó de fons és sempre la mateixa: en arquitectura no hi ha solucions perfectes, només compromisos ben raonats. La teva feina com a arquitecte no és eliminar els compromisos, sinó triar-los conscientment, justificar-los i deixar el sistema preparat per canviar quan els compromisos d'avui deixin de servir. Enhorabona per completar el curs.