La Marta ha pres la decisió i el Luis té l'encàrrec d'executar-la. Abans de dibuixar ni un sol servei, l'equip necessita un conjunt de principis de disseny compartits: regles senzilles que serveixin per jutjar cada decisió ("aquest límit és bo?", "aquesta crida està ben col·locada?", "aquest servei és massa petit?"). Sense principis explícits, cada desenvolupador dissenyarà segons la seva intuïció i el resultat serà el monòlit distribuït contra el qual ja ens va prevenir la lliçó 01-04.

Aquesta lliçó presenta els deu principis que guiaran tot el mòdul 2 i, de fet, tot el curs: cohesió i acoblament, responsabilitat única, autonomia, contracte com a única porta, dades descentralitzades, disseny per a la fallada, mida adequada, Llei de Conway, smart endpoints, dumb pipes i automatització. Perquè no es quedin en teoria, cada principi s'aplica al monòlit de TechCorp i, al final, tornem sobre els sis problemes que vam anotar a crearComanda a la lliçó 01-05 per classificar-los segons el principi que violen. La descomposició en si (quins serveis surten del monòlit) és el tema de 02-02, i la definició de les seves fronteres, el de 02-03: aquí fixem el criteri amb què les jutjarem.

1. Per què començar pels principis i no per les caixes
2. Alta cohesió i baix acoblament: els quatre tipus d'acoblament
3. Responsabilitat única i modelatge al voltant de capacitats de negoci
4. Autonomia i desplegament independent
5. El contracte com a única porta: amagar els detalls interns
6. Dades descentralitzades (enunciat)
7. Disseny per a la fallada (enunciat)
8. Mida adequada: "micro" no vol dir diminut
9. La Llei de Conway aplicada als equips de TechCorp
10. Smart endpoints, dumb pipes
11. L'automatització com a principi de disseny
12. Radiografia de crearComanda: quin principi trenca cada problema

Quan un equip decideix "fer microserveis", la temptació immediata és obrir una pissarra i dibuixar caixes. El problema és que les caixes es dibuixen soles: sis àrees del monòlit, sis serveis, llestos. El que no es dibuixa sol és la qualitat de les fronteres entre aquestes caixes, i és aquí on un sistema distribuït triomfa o fracassa.

Els principis serveixen per a tres coses:

• Decidir amb criteri quan el domini no és evident. A TechCorp, la reserva d'estoc pertany a Inventari o a Comandes? Les adreces d'enviament són de Clients o de Comandes? Els principis donen la resposta raonada; la intuïció, no.
• Revisar dissenys d'altres amb un vocabulari comú. Quan el Luis revisi el disseny de l'equip de Pagaments, vol poder dir "això introdueix acoblament temporal", no "això no m'agrada".
• Detectar la deriva amb el temps. Els sistemes es degraden per acumulació de petites excepcions ("només aquest cop llegeixo la taula d'un altre servei"). Els principis són la línia contra la qual mesurar la deriva.

Els principis que segueixen no són un invent del curs: provenen del treball de Sam Newman, Martin Fowler, James Lewis, Chris Richardson i la comunitat de DDD. El que fem aquí és ordenar-los i aterrar-los a la botiga de TechCorp.

És el principi mare; tots els altres són maneres d'aconseguir-lo.

• Cohesió: les coses que canvien juntes han de viure juntes. Si cada vegada que canvia una regla de negoci cal tocar tres serveis, la cohesió és baixa.
• Acoblament: el grau en què un canvi en un servei obliga a canviar (o afecta el funcionament d')un altre. Volem que sigui el mínim imprescindible.

La frase clàssica és "canviar una cosa hauria de requerir tocar un sol servei i desplegar només aquest servei". Al monòlit de TechCorp passa el contrari: quan Notificacions va canviar una consulta sobre comandes, va trencar un informe de Comandes (problema 3 de 01-05).

L'acoblament no és una sola cosa. Distingir-ne els tipus és el que permet atacar-lo:

Dues observacions importants:

• L'acoblament de contracte és el bo. Dos serveis que es comuniquen han de compartir alguna cosa: la forma del missatge. L'objectiu del disseny és que aquest sigui l'únic acoblament i que sigui explícit, petit i estable.
• L'acoblament temporal és el més traïdor, perquè no es veu al codi: una cadena de crides HTTP síncrones sembla neta i modular, però si cinc serveis es criden en cadena, la disponibilitat del conjunt és el producte de les cinc (0,99⁵ ≈ 0,95) i la latència, la suma. Un exemple esquemàtic:

Aquest codi "fa microserveis" i, tanmateix, reprodueix exactament el defecte del monòlit: la caiguda del correu continua impedint vendre. Fixa't que l'últim await és indefensable des del punt de vista del negoci: una comanda cobrada és una comanda, tant si s'ha enviat el correu com si no. Els principis serveixen precisament per detectar això abans d'escriure-ho.

Un microservei ha de tenir una raó per canviar, i aquesta raó ha de ser una capacitat de negoci: alguna cosa que l'empresa fa i que un responsable de negoci reconeixeria en una frase ("gestionar el catàleg", "cobrar comandes", "avisar el client").

El que no és una bona unitat de responsabilitat:

A TechCorp, les sis àrees funcionals de 01-05 (clients, catàleg, inventari, comandes, pagaments, notificacions) són capacitats de negoci recognoscibles: cadascuna té un responsable de negoci diferent, un vocabulari propi i un ritme de canvi propi (el catàleg canvia cada dia; les regles de cobrament, unes poques vegades l'any). És un senyal que el tall va ben encaminat, tot i que a 02-03 afinarem les fronteres amb més rigor.

Una prova ràpida que farà servir el Luis: "Puc explicar què fa aquest servei en una frase sense fer servir la paraula 'i'?". "Gestiona l'estoc i les reserves" passa (reservar forma part de gestionar l'estoc). "Crea comandes i envia correus" no passa.

Un servei és autònom quan el seu equip pot canviar-lo, provar-lo i desplegar-lo sense demanar permís ni coordinar-se amb altres equips, i quan pot continuar funcionant (encara que sigui de manera degradada) si els altres no hi són.

L'autonomia té tres cares:

1. Autonomia de codi: repositori o, com a mínim, mòdul amb propietari clar i pipeline propi.
2. Autonomia de dades: ningú més no llegeix ni escriu el seu emmagatzematge (principi 6).
3. Autonomia d'execució: no depèn que un altre servei sigui viu per respondre a les peticions que pot resoldre per si sol.

La prova de foc és el desplegament independent: si per posar en producció servei-cataleg v2.3 cal desplegar alhora servei-comandes, no hi ha autonomia, hi ha un monòlit repartit en diversos processos. És el problema 1 de TechCorp (desplegaments setmanals amb por, 4 de 12 revertits): el desplegament del dijous a la nit existeix perquè res no es pot desplegar per separat.

Autonomia no vol dir aïllament total: els serveis col·laboren. Vol dir que la col·laboració es fa a través de contractes estables (principi 5) i que la disponibilitat d'un no arrossega els altres (principi 7).

Un microservei exposa un contracte (una API HTTP, un conjunt d'esdeveniments publicats, o totes dues coses) i tota la resta és privada: les seves taules, les seves col·leccions, els seus fitxers, la seva estructura interna de mòduls, les seves decisions tecnològiques. És l'aplicació a escala de sistema de l'encapsulament que ja coneixes de la programació orientada a objectes.

Conseqüències directes:

• Cap servei no accedeix a la base de dades d'un altre. Ni per llegir. Ni "només per a un informe".
• Cap servei no importa codi de negoci d'un altre (require('../../servei-cataleg/models/producte') és una violació).
• Un servei pot canviar la seva tecnologia interna (de PostgreSQL a MongoDB, com farà el catàleg) sense que ningú se n'assabenti.
• El contracte és l'única cosa que cal versionar i protegir (03-06).

Compara les dues maneres que Comandes sàpiga el preu d'un producte:

Fixa't en el detall: a la segona versió, servei-comandes no sap que el catàleg té una columna actiu ni que existeix una taula productes. Només coneix el contracte. Quan a 02-04 el catàleg es traslladi a MongoDB, aquesta línia no canviarà.

Una conseqüència menys evident: el contracte ha d'expressar operacions de negoci, no operacions de dades. POST /reserves ("reserva aquestes quantitats per a aquesta comanda") és un contracte de negoci; PATCH /estoc/{id} amb { reservat: 7 } és exposar la taula per HTTP, i obliga els que el criden a conèixer la lògica interna de l'inventari (que reservat no pot superar quantitat, per exemple).

Cada servei és propietari exclusiu de les seves dades: en decideix l'esquema, la tecnologia i el cicle de vida, i és l'únic que les escriu. Els altres serveis obtenen aquestes dades a través del contracte (consultant l'API o subscrivint-se als esdeveniments que publica el propietari), mai llegint-ne l'emmagatzematge.

És el principi que més resistència genera, perquè té un cost real: es perden els JOIN entre àrees i es perd la transacció única. A TechCorp, és exactament el que fa crearComanda: una transacció que toca clients, productes, estoc, comandes, linies_comanda i pagaments. La lliçó 02-04 desenvolupa el patró database-per-service, com es trenquen les claus foranes creuades i quines alternatives hi ha per a les consultes que avui són un JOIN; la 02-05 substitueix la transacció per una saga. Aquí n'hi ha prou amb fixar la regla: una taula, un propietari.

En un monòlit, una crida a una funció no falla per culpa de la xarxa. En un sistema distribuït, tota interacció entre serveis pot fallar, trigar més del que s'espera o executar-se dues vegades. Les vuit fal·làcies de la computació distribuïda de 01-02 són la llista del que no es pot assumir.

Dissenyar per a la fallada significa, des de la fase de disseny:

• Decidir què fa cada servei quan la seva dependència no respon: falla?, respon amb dades de la memòria cau?, encua la feina per a més tard?
• Assumir que els missatges poden arribar duplicats i dissenyar operacions idempotents.
• Establir timeouts a tota crida sortint i no deixar mai una petició esperant indefinidament.
• Preferir la degradació parcial a la fallada total: si Notificacions cau, les comandes han de continuar entrant.

Els mecanismes concrets (reintents amb backoff, circuit breakers, bulkheads, cues de missatges fallits) s'estudien a 06-03. En aquest mòdul, el principi es tradueix en decisions de disseny: quines interaccions són síncrones i quines asíncrones, i quines compensacions hi ha quan un pas d'un flux falla (02-05).

El prefix "micro" ha fet molt de mal. No hi ha cap nombre de línies de codi, ni de taules, ni d'endpoints que defineixi la mida correcta. Els criteris útils són uns altres:

La regla pràctica: començar amb pocs serveis més grans i dividir quan hi hagi una raó (escalat diferent, equips diferents, ritme de canvi diferent). És molt més barat partir un servei que fusionar-ne dos que s'han dissenyat per separat amb contractes i bases de dades pròpies. Per això TechCorp no tindrà un servei-reserves separat de servei-inventari, ni un servei-linies-comanda separat de servei-comandes.

Melvin Conway va enunciar el 1967 que les organitzacions dissenyen sistemes que reflecteixen la seva estructura de comunicació. Si tres equips construeixen un compilador, en sortirà un compilador de tres passades. Aplicat als microserveis: si els equips estan organitzats per capa tècnica (front, back, BD), sortiran serveis per capa tècnica; si estan organitzats per capacitat de negoci, sortiran serveis per capacitat de negoci.

La conseqüència pràctica és la maniobra inversa de Conway: decidir primer l'arquitectura que es vol i organitzar els equips perquè la reflecteixin. A TechCorp, avui hi ha un únic equip de desenvolupament repartit informalment per àrees, tots sobre el mateix repositori; el 20 % de temps de coordinació de què es queixa el Luis és la Llei de Conway en acció.

La proposta de la Marta per acompanyar la migració:

Observa dues decisions:

• Cap servei no té dos equips propietaris i cap equip no té més serveis dels que pot mantenir. Un servei amb dos propietaris acaba amb dos criteris de disseny; un equip amb sis serveis acaba descuidant-ne quatre.
• Existeix un equip de plataforma que no és propietari de negoci, sinó de les eines comunes (clúster, pipelines, observabilitat). És la manera que l'automatització (principi 11) no recaigui en cada equip per separat.

Que Comandes i Inventari comparteixin equip no vol dir que comparteixin base de dades ni codi: els principis 5 i 6 s'apliquen igual dins d'un equip. El que comparteixen és ritme i context: són les dues peces que més conversen en el flux de comanda i convé que les converses de disseny siguin barates.

Aquest principi, formulat per Fowler i Lewis, és una reacció a l'època SOA que vam repassar a 01-01: aleshores, l'Enterprise Service Bus (la "canonada") concentrava lògica de negoci: transformacions, encaminament per contingut, orquestracions complexes. El resultat era un bus intel·ligent envoltat de serveis ximples, i el bus es convertia en un monòlit central que ningú no gosava tocar.

En microserveis s'inverteix:

• Els extrems són intel·ligents: la lògica de negoci viu als serveis. servei-inventari decideix si pot reservar; ningú no decideix per ell.
• Les canonades són ximples: HTTP i el broker de missatges (RabbitMQ al curs) transporten bytes. Encaminen, lliuren, reintenten, però no saben què és una comanda.

Què implica per al disseny de TechCorp:

Quan a 05-05 aparegui el service mesh (Istio), veurem que també respecta aquest principi: la malla s'ocupa de xarxa, seguretat i observabilitat, mai de lògica de negoci.

Pot sorprendre que l'automatització sigui un principi de disseny i no d'operacions. La raó és que un disseny de sis, dotze o vint serveis és inviable sense automatització, i per tant l'automatització condiciona el disseny des del primer dia:

• Si el desplegament no és automàtic, ningú no desplegarà serveis de manera independent i es tornarà al "dijous a la nit".
• Si les proves de contracte no són automàtiques, ningú no gosarà canviar un contracte.
• Si la creació d'un servei nou no està automatitzada (plantilla, pipeline, tauler de mètriques), el cost de crear un servei serà tan alt que es ficarà tot als existents.
• Si no hi ha observabilitat automàtica, un flux repartit en cinc serveis serà impossible de depurar.

Per això el disseny de TechCorp inclou, com a part del sistema i no com a afegit, GitHub Actions (05-03), Docker i Kubernetes (05-01, 05-02), Prometheus/Grafana/Loki (06-01) i OpenTelemetry (06-02). I per això existeix l'equip de plataforma de l'apartat 9. La regla del Luis: "Si s'ha de fer més d'un cop per servei, s'automatitza abans de crear el segon servei".

A 01-05 vam anotar sis problemes al codi de crearComanda. Ara els podem classificar amb precisió, i aquesta classificació és el guió de les lliçons que vénen:

I hi ha un setè problema que aleshores no vam anotar perquè encara no teníem vocabulari: el desplegament. crearComanda viu al mateix artefacte que la cerca del catàleg, així que un canvi en com s'ordenen els resultats de cerca obliga a redesplegar la lògica de cobrament. És acoblament de desplegament pur, viola l'autonomia, i és el que les lliçons del mòdul 5 resolen un cop el disseny ho permet.

Aquest quadre és el "contracte" del mòdul 2 amb el lector: en acabar 02-05, cada fila tindrà una solució dissenyada.

• Confondre "principi" amb "regla absoluta". Els principis es ponderen. De vegades s'accepta acoblament temporal (una consulta síncrona a Catàleg per mostrar preus) perquè l'alternativa (replicar tot el catàleg) és pitjor. L'important és que l'excepció sigui conscient i estigui documentada.
• Buscar "microserveis petits" en lloc de "microserveis autònoms". La mida és una conseqüència, no un objectiu. Un servei de 30 000 línies que un equip desplega deu vegades al dia sense coordinar-se amb ningú és un bon microservei.
• Dissenyar serveis i deixar els equips com estaven. La Llei de Conway s'imposa sempre. Si un sol equip manté sis serveis amb sis repositoris, acabarà desplegant-los junts "per simplificar".
• Exposar la base de dades per HTTP. GET /estoc/{id} que retorna la fila tal qual i PATCH /estoc/{id} per modificar-la no és un contracte de negoci, és acoblament de dades disfressat. Els contractes parlen de reserves, cobraments i comandes.
• Deixar l'automatització "per a després". Després no arriba mai, i sense ella el segon servei ja fa mal.
• Consell: escriu els principis en una pàgina del wiki de l'equip, amb un exemple de TechCorp per principi, i fes-los servir com a llista de comprovació a cada revisió de disseny. És el que farà el Luis a partir d'aquesta setmana.

Per a cada situació del monòlit de TechCorp, indica quin(s) tipus d'acoblament descriu (temporal, de desplegament, de dades, de contracte) i quin principi s'està violant:

1. Quan Comandes va afegir una columna a linies_comanda, la migració va fallar per un bloqueig amb una consulta pesada de Catàleg.
2. Un canvi a la plantilla del correu de confirmació obliga a executar la suite completa de 40 minuts i a desplegar el dijous.
3. Si la passarel·la de pagament triga 8 segons a respondre, la petició POST /comandes triga 8 segons i les files d'estoc queden bloquejades mentrestant.
4. El mòdul d'informes importa directament controladors/comandesControlador.js per reutilitzar una funció que calcula totals.

Aplica la prova "ho puc descriure en una frase sense 'i'?" a aquests candidats a servei i decideix si són una capacitat de negoci vàlida, un servei massa gran o un nanoservei. Justifica-ho en una línia:

1. servei-calcul-iva
2. servei-inventari (estoc, reserves, alliberaments, entrades de magatzem)
3. servei-comandes-i-facturacio
4. servei-notificacions (correus i SMS a partir d'esdeveniments)

La Marta proposa una organització alternativa: un equip "Back-end" (tots els serveis), un equip "Front-end" i un equip "Dades" (totes les bases de dades). Explica en 4-6 línies quina arquitectura prediu la Llei de Conway per a aquesta organització i per què és incompatible amb els principis 4, 5 i 6.

Exercici 1

1. Acoblament de dades (dues àrees sobre el mateix esquema físic) amb efecte de desplegament (la migració de l'una bloqueja l'altra). Viola dades descentralitzades i autonomia.
2. Acoblament de desplegament: un canvi trivial d'una capacitat arrossega el desplegament de totes. Viola autonomia i desplegament independent; de fons, automatització (una suite de 40 minuts no permet desplegaments freqüents).
3. Acoblament temporal amb la passarel·la, agreujat per l'acoblament de dades (bloqueig d'estoc, que és d'una altra àrea). Viola disseny per a la fallada i dades descentralitzades.
4. Acoblament de contracte implícit i no gestionat (depèn de la signatura interna d'una funció que no és un contracte públic) i, en el fons, viola el contracte com a única porta: els informes haurien de consumir una API o un esdeveniment, no codi intern d'una altra àrea.

Exercici 2

1. servei-calcul-iva: nanoservei. És una funció, no una capacitat; ningú de negoci no diria "la nostra capacitat de calcular l'IVA". Hauria de ser una llibreria o part de Comandes/Pagaments.
2. servei-inventari: capacitat vàlida. "Gestiona l'estoc" (reservar i alliberar són operacions de l'estoc). Un responsable de magatzem el reconeix.
3. servei-comandes-i-facturacio: massa gran o, com a mínim, dues capacitats amb ritmes i responsables diferents (vendes vs. comptabilitat). Candidat a dividir-se tan bon punt hi hagi una raó (per exemple, requisits fiscals que canvien sense tocar el cicle de la comanda).
4. servei-notificacions: capacitat vàlida. "Avisa el client del que passa" és una frase sense "i" (correu i SMS són canals de la mateixa capacitat, no capacitats diferents).

Exercici 3

La Llei de Conway prediu una arquitectura per capes: un gran "back-end" (que tendiria a ser un únic servei o un conjunt de serveis que es despleguen junts perquè un sol equip els manté), un front-end a part i una base de dades compartida gestionada per l'equip de Dades, amb esquemes dissenyats per aquest equip per a tothom. És incompatible amb l'autonomia (cap equip no pot desplegar una capacitat de negoci de punta a punta sense coordinar-se amb els altres dos), amb el contracte com a única porta (l'equip de Dades accediria a tot i els serveis compartirien taules per disseny) i amb dades descentralitzades (hi hauria un propietari únic de totes les bases de dades, és a dir, la BD compartida de 01-01: un monòlit distribuït). Per obtenir microserveis autònoms, els equips han de ser verticals per capacitat de negoci, amb un equip de plataforma horitzontal només per a les eines.

Hem fixat el criteri amb què jutjarem tot el que dissenyem: alta cohesió i baix acoblament (distingint acoblament temporal, de desplegament, de dades i de contracte), responsabilitat única al voltant de capacitats de negoci, autonomia amb desplegament independent, el contracte com a única porta, dades descentralitzades, disseny per a la fallada, mida adequada (equips de dues pizzes, "que càpiga al cap"), Llei de Conway aplicada als quatre equips de TechCorp, smart endpoints, dumb pipes i automatització des del disseny. I hem tornat sobre crearComanda per classificar-ne els sis problemes (més el de desplegament) segons el principi que trenquen: baixa cohesió, acoblament de dades, transacció única, acoblament temporal amb la passarel·la i amb el correu, i manca d'idempotència.

Amb aquests principis com a llista de comprovació, la lliçó següent aborda la primera gran pregunta pràctica: com es descompon el monòlit. Veurem les estratègies (per capacitat de negoci, per subdomini, per casos d'ús, per equips), les tècniques per descobrir les costures (inclosa l'anàlisi d'acoblament de l'esquema SQL de 01-05), les tècniques d'extracció segura i, sobretot, en quin ordre extraurà TechCorp els seus sis serveis i per què el catàleg va primer.