Hem arribat al final. TechCorp ha passat d'un monòlit amb cinc problemes mesurables (01-05) a sis serveis operats amb SLOs, desplegats onze vegades al dia i assegurats per capes; hem explicat la migració (08-01), hem escrit el sistema complet (08-02) i l'hem desplegat i operat (08-03). Aquesta última lliçó no afegeix res de nou al sistema: destil·la el que hem après perquè t'ho enduguis al teu propi context. Primer, les lliçons de TechCorp organitzades per dimensió, cadascuna en la forma més honesta possible ("què vam fer, què va sortir malament, què faríem diferent"). Després, el catàleg d'antipatrons que hem vist i com reconèixer-los a temps. Tot seguit, una llista consolidada de bones pràctiques amb la lliçó on s'explica cadascuna, el que TechCorp faria a la seva fase 2 i amb quin criteri, i una guia per a l'alumne: com decidir, per on començar, com practicar amb l'entorn del curs i què llegir després. I el tancament: el recorregut mòdul a mòdul i les paraules finals de la Marta i el Luis.

1. Lliçons apreses per dimensió
2. Catàleg d'antipatrons i com detectar-los
3. Llista consolidada de bones pràctiques
4. Què faria TechCorp a la fase 2
5. Guia per a l'alumne: aplicar el curs al teu context
6. Lectures i recursos recomanats
7. Tancament del curs (a la conclusió)

Cada taula resumeix una dimensió del curs. La columna "què faríem diferent" és la més útil: és el que TechCorp escriuria al postmortem del projecte.

Tots han aparegut al curs, gairebé tots a TechCorp. La columna "com detectar-lo" és una prova que pots aplicar al teu sistema demà mateix.

Vint-i-cinc punts, agrupats, amb la lliçó de referència. Fes-la servir com a checklist de revisió d'arquitectura o d'un servei nou.

Decisió i disseny

1. Adopta microserveis per problemes mesurables, no per moda; construeix els quatre prerequisits sobre el monòlit i modularitza'l primer (01-04, 02-02, 08-01 fase 0).
2. Talla per capacitats de negoci i bounded contexts; valida amb event storming i la matriu taula × àrea (02-02, 02-03).
3. Un servei = les seves dades: base de dades (o esquema) pròpia, ids opacs, sense FK creuades, rèpliques de lectura per esdeveniments (02-04).
4. Substitueix la transacció distribuïda per una saga amb màquina d'estats explícita, compensacions com a esdeveniments i un vigilant (02-05, 06-03 §9).
5. Extreu en ordre de valor/risc/dependències amb strangler fig darrere d'un gateway i branch by abstraction amb flags; mai no esborris el que és antic el dia del tall (02-02, 08-01).

Comunicació 6. Contractes primer (OpenAPI/AsyncAPI), errors RFC 7807 amb codi, 202 per a processos asíncrons, ETag per a polling (03-01). 7. Esdeveniments amb sobre estàndard (esdevenimentId, tipus, versio, ocorregutEn), topic exchange, cua per consumidor amb reintent diferit i DLQ (03-02, 06-03 §8). 8. Outbox transaccional per publicar; processarUnCop + idempotència de negoci (UNIQUE) per consumir; Idempotency-Key als POST (02-05 §7-8, 04-04, 08-02). 9. Gateway prim; composició al BFF o al servei; ACL a cada frontera (03-04, 02-03). 10. Versiona: afegeix sense treure, /v2/ només per a incompatibles, Deprecation/Sunset, upcasting d'esdeveniments, pactes HTTP i de missatges amb can-i-deploy (03-06, 04-05, 05-03 §4).

Implementació 11. Plantilla de servei + llibreria tècnica versionada; el negoci no es comparteix (04-01, 02-02 §6). 12. crearApp sense listen, injecció de dependències per paràmetre, capes cap endins (04-02). 13. Configuració validada en arrencar, fail-fast, secrets fora del codi i de la imatge (04-03, 07-03 §7). 14. Piràmide: unitàries del domini, component amb dobles, integració amb Testcontainers, contracte amb Pact, una E2E (04-05). 15. Cap crida externa dins d'una transacció; transaccions curtes i consulta per clau d'idempotència davant del dubte (01-05, 08-02 §4).

Plataforma i desplegament 16. Imatges multi-stage, no root, etiquetades per sha i semver, escanejades i signades; mai latest (05-01, 07-04 §2). 17. Kustomize base + overlays per entorn; Helm per a tercers amb values versionats; sondes, securityContext, PDB, requests reals (05-02, 06-04, 07-04). 18. GitOps: producció canvia per PR; Argo CD sincronitza; rollback = revertir commit (05-03 §6). 19. Desplegaments progressius per servei (rolling, canary, blue-green) amb expand/contract i compatibilitat d'esdeveniments (05-04). 20. Workflow de CI reutilitzable i versionat; la regla del Luis (05-03 §11).

Operació i seguretat 21. Logs estructurats amb redact, mètriques RED i de negoci amb etiquetes acotades, traces amb context propagat per HTTP i per esdeveniments (06-01, 06-02). 22. Timeouts sempre, reintents només del que és transitori amb backoff, circuit breaker, bulkhead, DLQ amb runbook (06-03). 23. SLOs amb pressupost d'error, alertes per símptoma i burn rate, guàrdia amb runbooks, postmortems sense culpa amb accions (06-05). 24. Identitat portable (OIDC/JWT) verificada al gateway i a cada servei; autorització per rol, scope i propietari; TLS a tot arreu; webhooks signats (07-01, 07-02). 25. Validació estricta d'entrada, RGPD per disseny (minimització, retenció, supressió), auditoria immutable, secrets per operador, NetworkPolicies deny-all, RBAC mínim, i una llista de pendents honesta (07-03, 07-04).

Res d'això és urgent; cada punt té un criteri que diu quan abordar-lo. És la diferència entre un full de ruta i una llista de desitjos.

Decidir. Torna a la matriu de 01-04 i respon amb dades, no amb opinions:

Quatre o més "sí" amb els prerequisits llestos: extreu de manera incremental començant per la raó més clara. Menys: monòlit modular i revisió d'aquí a sis mesos. I recorda que la llista de 01-04 té senyals d'alarma (equip de tres persones, "perquè ho fa Netflix", sense automatització) que anul·len tota la resta.

Per on començar (si decideixes continuar): en aquest ordre, i sense saltar-te'n cap: (1) els quatre equips —o els que tinguis— amb propietat clara; (2) CI i imatge del monòlit; (3) gateway al davant i observabilitat mínima; (4) matriu taula × àrea i monòlit modular; (5) primera extracció per valor/risc/dependències amb càrrega inicial, esdeveniments, ombra i flag; (6) SLO i alerta del servei nou abans de donar-lo per fet; (7) plantilla i llibreria abans del segon servei.

Com practicar. L'entorn del curs està pensat per reproduir-se:

• Aixeca TechCorp en local amb el compose.yaml de 08-03 §2, obtén un token de Keycloak i segueix com-88213 per Jaeger, Grafana i Loki com a 08-03 §5. Trenca coses: atura servei-pagaments i observa el vigilant i la DLQ; publica un esdeveniment mal format amb publicarEsdeveniment.js i reprocessa'l; esgota l'estoc de p-802.

• Exercicis d'extensió proposats, de menor a major: cupons i promocions (01-03, 02-02 ex. 2, 08-01 §11): primer com a mòdul de Comandes, després decideix amb criteri si mereix servei; devolucions: nou estat de la comanda, pagament.reemborsat com a branca habitual, estoc.reposat, correu, auditoria; enviaments: un servei-enviaments que consumeixi comanda.confirmada, parli amb un transportista fictici (ACL, webhook signat, reintents) i publiqui comanda.enviada/comanda.lliurada que Notificacions i l'analítica consumeixin; v2 de comanda.creada amb upcasting i pactes de missatges; Argo Rollouts per al canary de Comandes amb anàlisi de slo:comandes_error_ratio.
• Repeteix el mòdul 6 sobre la teva pròpia extensió: mètriques, SLO, alerta, runbook i un game day en què un company trenqui alguna cosa sense avisar.

Sense URLs (canvien); cerca per títol i projecte. Llibres:

• Sam Newman, Building Microservices (2a ed.) i Monolith to Microservices: la referència general i el manual de l'strangler fig que TechCorp va seguir (mòduls 1, 2 i 8).
• Chris Richardson, Microservices Patterns: sagues, outbox, CQRS, API composition; el lloc microservices.io de l'autor cataloga els patrons (02-05, 03-04).
• Eric Evans, Domain-Driven Design; Vaughn Vernon, Implementing Domain-Driven Design; Vlad Khononov, Learning Domain-Driven Design: bounded contexts, mapa de contextos, agregats (02-03).
• Martin Kleppmann, Designing Data-Intensive Applications: consistència, replicació, missatgeria, la base teòrica de 02-04 i 02-05.
• Gregor Hohpe i Bobby Woolf, Enterprise Integration Patterns: missatgeria, DLQ, idempotència (03-02, 06-03).
• Michael Nygard, Release It! (2a ed.): timeouts, circuit breaker, bulkhead, estabilitat (06-03).
• Betsy Beyer i altres (Google), Site Reliability Engineering i The Site Reliability Workbook: SLOs, burn rate, guàrdies, postmortems (06-05).
• Nicole Forsgren, Jez Humble i Gene Kim, Accelerate: les mètriques DORA (05-03, 08-01 §10).
• Matthew Skelton i Manuel Pais, Team Topologies: equips alineats a flux i equip de plataforma (02-01, 08-04 §1.1).
• Jez Humble i David Farley, Continuous Delivery; Marko Lukša, Kubernetes in Action: la base dels mòduls 5 i 8.
• Neal Ford, Mark Richards, Pramod Sadalage i Zhamak Dehghani, Software Architecture: The Hard Parts: granularitat, dades i sagues amb trade-offs explícits.

Documentació oficial i projectes que convé tenir a mà: Node.js i Express; PostgreSQL i MongoDB; RabbitMQ (guies de fiabilitat, DLX i TTL); Docker i Compose; Kubernetes (conceptes, Kustomize), Helm, kind, KEDA, Argo CD i Argo Rollouts, ingress-nginx, cert-manager, External Secrets Operator; GitHub Actions; Prometheus, Grafana, Loki, OpenTelemetry (JavaScript SDK) i Jaeger; Keycloak; Pact (inclosos els pactes de missatges) i el Pact Broker; Trivy i Sigstore/cosign; OWASP API Security Top 10; The Twelve-Factor App; i les especificacions OpenAPI, AsyncAPI, RFC 7807 i W3C Trace Context.

• Convertir la llista de bones pràctiques en dogma. Cada punt de l'apartat 3 té una lliçó amb el seu context i els seus trade-offs; aplicat sense el context (per exemple, outbox en un servei que no publica res de crític) afegeix complexitat sense benefici. Llegeix la lliçó abans d'imposar la pràctica.
• Copiar l'arquitectura final de TechCorp en lloc del seu mètode. Sis serveis, RabbitMQ i Kubernetes són la resposta als cinc problemes de 01-05 amb 25 tècnics; amb tres persones i un domini canviant, la resposta correcta de la matriu de 01-04 és un monòlit modular.
• Confondre "fase 2" amb "pendent". Mesh, event sourcing, gRPC o Go tenen un criteri d'activació; abordar-los abans que es compleixi és el "perquè ho fa Netflix" de què 01-04 avisava.
• Postmortem sense accions o accions sense data. Les taules de l'apartat 1 són postmortems del projecte; el seu valor és a la columna "què faríem diferent" convertida en tasques amb amo.
• Practicar només el camí feliç. L'entorn local serveix per trencar: atura Pagaments, esgota l'estoc, publica esdeveniments mal formats, rota un secret. El que no has vist fallar en local ho veuràs fallar a producció.
• Consell: guarda la teva pròpia versió de les taules de l'apartat 1 des del primer dia del teu projecte, encara que estiguin gairebé buides. La disciplina d'omplir-les cada trimestre val més que qualsevol eina.

Aplica la matriu de l'apartat 5 a un sistema que coneguis (el de la teva feina, un projecte personal o, si no en tens cap, un sistema de reserves d'un hotel amb 4 tècnics). Respon les cinc preguntes amb dades concretes, indica quina recomanació en surt i, si és "extreure", quin seria el primer servei i què faria la teva fase 0.

Un equip descriu el seu sistema així: "Tenim vuit serveis a Kubernetes. Comparteixen una base de dades PostgreSQL amb esquemes separats per servei, però el servei d'informes fa JOIN entre esquemes. Despleguem els vuit junts cada dues setmanes perquè un canvi a la llibreria models-comuns obliga a actualitzar-los tots. Els serveis es criden per HTTP en cadena i, quan el de clients triga, tot triga. Cada servei reintenta les crides fallides tres vegades seguides." Identifica tots els antipatrons de l'apartat 2 que hi apareixen, ordena'ls pel dany que fan i proposa per a cadascun la primera acció, amb la lliçó de referència.

La Marta té pressupost per a dues iniciatives de la taula de l'apartat 4 el semestre vinent. Amb les dades del curs (08-01 §10-11, 08-03 §11, SEGURETAT.md), tria'n dues, justifica-ho amb el criteri de cadascuna i explica per què en descartes almenys tres altres que semblen atractives.

Exercici 1. No hi ha una única resposta; la solució és el mètode. Per a l'hotel de 4 tècnics: (1) un equip, sense destorbs → no; (2) probablement sense CI complet ni observabilitat → no; (3) reserves i facturació tenen càrregues semblants; potser el motor de disponibilitat en temporada alta → feble; (4) domini conegut → sí; (5) la velocitat la frena la manca de proves, no el desplegament → no. Resultat: monòlit modular amb mòduls per capacitat (reserves, facturació, disponibilitat, clients), CI, contenidor, observabilitat i SLIs des d'ara; revisar d'aquí a 6-12 mesos. Si al teu sistema real surten quatre "sí" amb els prerequisits llestos, el primer servei és el que tingui la raó més clara i menys dependències (el "catàleg" del teu domini) i la fase 0 és la llista de l'apartat 5 ("per on començar").

Exercici 2. Per dany: (1) Base de dades compartida (els JOIN del servei d'informes creuen esquemes: qualsevol canvi d'esquema trenca informes) → matriu taula × servei i BD de lectura per a informes alimentada per esdeveniments (02-02 §3.3, 02-04 §8); (2) Llibreria de models compartida + monòlit distribuït (vuit serveis desplegats junts per models-comuns) → substituir per contractes per servei i una llibreria només tècnica versionada; cada servei defineix els seus DTOs (02-02 §6, 03-06); (3) Sincronia en cadena amb reintents immediats (tot triga quan triga clients; tres reintents seguits multipliquen la càrrega: tempesta de reintents) → timeouts amb pressupost, circuit breaker, reintents amb backoff només del que és transitori, i substituir les crides no necessàries a la petició per esdeveniments o rèpliques de lectura (06-03, 02-04 §4, 03-02); (4) Desplegament conjunt cada dues setmanes (símptoma, no causa) → desapareix en resoldre 1-2; mesurar DORA per comprovar-ho (05-03 §12). No hi apareixen (o no se sap): gateway gras, secrets, cardinalitat; preguntar.

Exercici 3. Una resposta defensable: (a) FinOps — criteri "ja": la factura és de 2.760 €/mes amb palanques identificades de ~800 € (08-03 ex. 3); cost de la iniciativa baix (etiquetes i un informe); retorn immediat que a més finança la resta. (b) Pendents de SEGURETAT.md (cosign en admissió, PSA enforce, ESO per a tots) — criteri "trimestre següent"; risc conegut, cost acotat, i desbloqueja l'auditoria de Pagaments que al seu torn activarà el mesh. Descartaments: mesh/mTLS ara — el seu criteri (auditoria o >12 serveis) encara no es compleix i costa d'operar (05-05); event sourcing — ningú no ha demanat l'historial complet i l'auditoria de 07-03 cobreix el que és sensible; Go per a Inventari — no hi ha cost ni latència mesurats que ho justifiquin (regla de la Marta); gRPC Comandes↔Inventari — la saga compleix el seu SLO de 60 s amb p95 de 3 s; IDP — amb 6 serveis i un README, no compensa. L'important no són les dues triades sinó que cada descartament es recolzi en el criteri de la taula i no en l'atractiu de la tecnologia.

El recorregut, mòdul a mòdul. Al mòdul 1 vam aprendre què és un microservei, què s'hi guanya i què s'hi paga, com es compara amb el monòlit, quan té sentit fer el pas i vam conèixer TechCorp: un monòlit amb cinc problemes i una funció, crearComanda, que feia sis coses de cinc àrees. Al mòdul 2 vam dissenyar: principis i acoblaments, descomposició amb event storming i la matriu de taules, bounded contexts i el mapa de contextos, una base de dades per servei i la migració sense dual write, i la saga per coreografia amb outbox i idempotència que va substituir la transacció. Al mòdul 3 vam fer parlar els serveis: contractes REST amb 202, ETag i Idempotency-Key; RabbitMQ amb la seva topologia i les seves DLQ; gRPC i GraphQL com a candidats; el gateway i el BFF; descobriment i sondes; versionat i pactes. Al mòdul 4 vam escriure codi: la plantilla i la llibreria, servei-cataleg, la configuració validada, servei-comandes amb el seu outbox i els seus consumidors, i la piràmide de proves. Al mòdul 5 ho vam empaquetar i desplegar: Docker i Compose, Kubernetes amb Kustomize, CI/CD amb GitHub Actions, Pact Broker i Argo CD, desplegaments progressius, i l'avaluació honesta del mesh. Al mòdul 6 ho vam fer operable: logs, mètriques i traces; resiliència i recuperació; escalat; SLOs, alertes, guàrdies, runbooks i el postmortem d'INC-2031. Al mòdul 7 ho vam assegurar per capes: Keycloak i JWT, TLS i signatures, codi validat i RGPD, plataforma endurida. I al mòdul 8 ho vam unir: la migració explicada en ordre, els quatre serveis que faltaven, el sistema desplegat i operat, i aquestes lliçons.

Paraules de la Marta. "Quan vaig presentar el pla el juliol de 2025 em van preguntar per què no reescrivíem la botiga d'una vegada. Tretze mesos després, la resposta és als números que no vam haver d'explicar: cap dia sense vendre, onze desplegaments al dia, un incident seriós que va durar quaranta minuts i del qual vam aprendre més que de dos anys de dijous a la nit. Però el que més valoro no és a la taula: avui cada equip sap què és seu, ho mesura i ho millora sense demanar permís. Els microserveis van ser el mitjà; el fi era una organització que pogués canviar la botiga cada dia sense por. Si hagués de resumir el projecte en una frase per a una altra CTO: no comencis pels serveis, comença pels deures; i no esborris res el dia del tall."

Paraules del Luis. "Jo em quedo amb tres coses. La primera, que la millor decisió tècnica de l'any va ser la menys vistosa: retornar les escriptures d'estoc i pagaments al seu amo dins del monòlit abans de moure una línia de servidor. La segona, que gairebé tot el que ens va salvar a producció era avorrit i estava escrit abans de necessitar-ho: l'UNIQUE (comanda_id), el processarUnCop, el vigilant, la clau d'idempotència cap a la passarel·la, la cua de reintent. I la tercera, que la regla de 'si es fa més d'un cop per servei, s'automatitza abans del segon' és més fàcil de dir que de complir —el ci.yml es va copiar tres vegades— i tot i així és la que fa que sis serveis els pugui operar un equip de vint-i-cinc persones. A qui estigui començant: torneu a llegir crearComanda de 01-05, ara que sabeu en què es va convertir. Tot el curs és a la distància entre aquelles 80 línies i com-88213 creuant quatre bases de dades en tres segons."

Per a tu. Has recorregut el mateix camí que TechCorp, amb les seves decisions i les seves ensopegades. El que t'endús no és una llista de tecnologies —canviaran— sinó un mètode: mesurar abans de decidir, fer els deures abans de dividir, tallar per capacitats i dades, comunicar per contractes i esdeveniments idempotents, automatitzar abans del segon ús, desplegar en petit i sovint, observar i acordar què és "anar bé", assegurar per capes i aprendre per escrit de cada incident. Aixeca TechCorp al teu portàtil, trenca-la, amplia-la amb cupons, devolucions o enviaments, i després aplica el mètode al teu propi sistema, començant per la fase 0. Els microserveis no són la destinació; són una manera que la teva organització pugui canviar el seu programari amb confiança, una comanda —i un desplegament— cada vegada. Gràcies per arribar fins aquí, i bona sort amb la teva pròpia migració.