Amb els principis de disseny com a llista de comprovació, l'equip del Luis s'enfronta a la pregunta pràctica: per on es talla el monòlit? Descompondre no és dibuixar sis caixes amb els noms de les carpetes del repositori. És trobar les costures reals del sistema (els llocs on el codi i les dades ja estan, o poden estar, poc acoblats), decidir una estratègia de tall coherent, triar un ordre d'extracció que minimitzi el risc i aplicar tècniques que permetin extreure peces sense aturar la botiga.

En aquesta lliçó recorrem les estratègies de descomposició (per capacitat de negoci, per subdomini, per casos d'ús enfront de recursos, per equips), les tècniques per descobrir les costures (event storming introductori, anàlisi de dependències del codi i anàlisi d'acoblament de les taules de l'esquema SQL de 01-05), les dues tècniques d'extracció segura més utilitzades (strangler fig i branch by abstraction), els criteris per ordenar l'extracció i què fer amb les utilitats compartides com bd/connexio.js o serveis/correu.js. Acabem amb l'exemple guiat: el monòlit techcorp-shop descompost en els sis serveis del mapa objectiu, amb el diagrama de dependències abans i després. Com es reparteixen físicament les dades (02-04) i com se substitueix la transacció única (02-05) queden per a les lliçons següents.

1. Què significa descompondre (i què no)
2. Estratègies de descomposició
3. Tècniques per descobrir les costures
4. Extreure sense trencar: strangler fig i branch by abstraction
5. En quin ordre extreure: risc, valor i dependències
6. Què fer amb les utilitats compartides
7. Exemple guiat: techcorp-shop en sis serveis

Descompondre un monòlit és redistribuir responsabilitats, codi i dades en unitats autònomes que compleixin els principis de 02-01. Tres aclariments eviten malentesos freqüents:

• No és "un servei per carpeta". Que el monòlit tingui controladors/comandesControlador.js no garanteix que "comandes" sigui una bona frontera: com hem vist, aquesta funció toca cinc àrees. Les carpetes són una pista, no la resposta.
• No és "un servei per taula". Seria el servei d'entitat de 01-04. Un servei agrupa les taules que canvien juntes sota una capacitat.
• No és un acte únic. És un procés incremental en què cada extracció deixa el sistema funcionant i aporta valor per si mateixa. Si una extracció només té sentit "quan hi siguin totes", és un big bang disfressat.

El resultat de la descomposició és un pla: quins serveis hi haurà, què s'emporta cadascun del monòlit, en quin ordre s'extreuen i amb quina tècnica. Aquest pla és el lliurable d'aquesta lliçó per a TechCorp.

Hi ha quatre maneres habituals de decidir les fronteres. No són excloents: a la pràctica es combinen, i una serveix per validar-ne una altra.

Es pregunta "què fa l'empresa?" i es respon amb una llista de capacitats estables en el temps: gestionar el catàleg, controlar l'inventari, tramitar comandes, cobrar, atendre clients, comunicar-s'hi. Cada capacitat té un responsable de negoci, un vocabulari i un ritme de canvi propis (principi 3 de 02-01).

És l'estratègia més utilitzada perquè les capacitats canvien molt menys que la tecnologia o l'organització: TechCorp cobrava comandes fa deu anys i les cobrarà d'aquí a deu, encara que canviï de passarel·la tres vegades.

El Domain-Driven Design parteix del domini (el negoci sencer) i el divideix en subdominis: parts del problema amb el seu propi model i el seu propi llenguatge. Sol produir fronteres molt semblants a les capacitats de negoci, però amb dues aportacions addicionals:

• Distingeix subdominis core (on l'empresa competeix), de suport i genèrics, cosa que ajuda a decidir on invertir esforç de disseny.
• Detecta que una mateixa paraula ("producte", "client") significa coses diferents en subdominis diferents, i que aquesta diferència de significat és una costura.

En aquesta lliçó fem servir DDD només com a estratègia de tall; la definició rigorosa dels bounded contexts de TechCorp, el llenguatge ubic i el mapa de contextos són el contingut de 02-03.

És una decisió de granularitat dins de qualsevol de les anteriors:

Per a TechCorp l'elecció és substantius com a base (comandes, productes, estoc, pagaments, clients) i el flux "fer una comanda" repartit entre ells mitjançant esdeveniments, sense un servei "checkout" separat. La raó es veurà amb detall a 02-05: el flux es coordina per coreografia i servei-comandes és propietari de l'estat de la comanda, no de les operacions dels altres. Si el flux es compliqués (devolucions parcials, comandes amb diversos enviaments), un servei orquestrador seria el moment de reconsiderar-ho.

De vegades es talla segons qui mantindrà què. És la Llei de Conway feta servir a propòsit (02-01, apartat 9): si Pagaments i Notificacions seran del mateix equip, han de ser un servei o dos? La resposta de TechCorp és dos, perquè tenen ritmes de canvi i perfils de risc diferents (Pagaments toca diners i una passarel·la externa; Notificacions toca plantilles i proveïdors de correu), però és legítim que l'organització influeixi en la granularitat final.

Les estratègies diuen com pensar; les tècniques diuen on mirar. TechCorp en fa servir tres, de més conversacional a més mecànica.

És un taller en què negoci i tècnics reconstrueixen el domini en una paret amb notes adhesives. En la seva versió mínima:

1. Esdeveniments de domini (taronja): fets rellevants en passat. "Comanda creada", "Estoc reservat", "Pagament confirmat", "Correu enviat", "Producte publicat", "Preu canviat", "Client registrat", "Estoc reposat".
2. Ordres (blau): la intenció que provoca l'esdeveniment. "Crear comanda", "Reservar estoc", "Cobrar".
3. Actors i sistemes externs (groc / rosa): client, operari de magatzem, passarel·la de pagament, proveïdor de correu.
4. S'ordenen en una línia temporal i es busquen esdeveniments pivot: aquells després dels quals canvia el vocabulari i canvien les persones que parlen.

El que es descobreix per a TechCorp, resumit:

Els grups d'esdeveniments que comparteixen vocabulari i actor són els candidats a servei; les fletxes discontínues entre grups són els esdeveniments que creuaran fronteres (els comanda.creada, estoc.reservat, pagament.confirmat, comanda.confirmada i comanda.cancellada de 01-05 surten literalment d'aquesta paret). Fixa't que hi apareixen dos esdeveniments que encara no havíem anomenat, "Estoc alliberat" i "Pagament reemborsat": són les compensacions que necessitarà la saga de 02-05. El taller també revela que "Preu canviat" no interessa a Comandes (una comanda desa el preu del moment de la compra), cosa que anticipa una decisió de dades de 02-03.

La segona tècnica és mecànica: qui importa qui dins del repositori del monòlit. Un graf de require/import (eines com madge o dependency-cruiser el generen en segons) mostra els mòduls amb moltes dependències entrants (difícils d'extreure perquè tothom els fa servir) i sortints (difícils d'extreure perquè fan servir tothom).

Resum del que veu l'equip del Luis a techcorp-shop:

La lliçó d'aquesta taula: en un monòlit amb base de dades compartida, el graf de require enganya. Els mòduls semblen independents perquè l'acoblament real passa per les taules. D'aquí la tercera tècnica.

Es construeix una matriu taula × àrea marcant qui llegeix (L) i qui escriu (E) cada taula, a partir del codi SQL del monòlit. Per a l'esquema de 01-05:

Com es llegeix:

• Una taula amb una sola E i cap L aliena (atributs_producte, notificacions) és una costura neta: s'extreu amb la seva àrea sense tocar res més.
• Una taula amb una E pròpia i diverses L alienes (clients, productes, comandes) s'extreu amb el seu propietari; les lectures alienes es converteixen en crides al contracte o en còpies de només lectura (02-04).
• Una taula amb dues E (estoc, pagaments) és un problema de disseny, no només d'extracció: avui crearComanda escriu a taules d'Inventari i de Pagaments. Abans d'extreure cal retornar l'escriptura al seu propietari (Comandes demanarà a Inventari que reservi, no reservarà ell). Aquesta és la primera refactorització que farà l'equip del Luis dins del monòlit, abans de moure res.

Aquesta matriu és l'eina més valuosa de tota la lliçó: converteix "crec que comandes està molt acoblat" en "comandes escriu a dues taules alienes i en llegeix dues més", que és una cosa sobre la qual es pot planificar.

Un cop decidit què extreure, cal com fer-ho amb la botiga funcionant. Dues tècniques cobreixen la majoria de casos. Aquí les presentem com a eines de descomposició; el relat complet de la migració de TechCorp, pas a pas, és a 08-01.

Es col·loca una façana (a TechCorp, l'API Gateway del port 8080) davant del monòlit. Al principi, tot el trànsit va al monòlit. Quan un servei nou està a punt, la façana redirigeix només les seves rutes al servei; la resta continua anant al monòlit. A poc a poc, el monòlit rep menys rutes fins a quedar buit i apagar-se.

Avantatges: reversible (si el servei nou falla, la façana torna a apuntar al monòlit), incremental i visible per al negoci (cada ruta migrada és una fita). Requisit: la façana ha d'existir abans de la primera extracció, cosa que la converteix en el primer lliurable tècnic del pla.

Serveix per a les dependències internes que la façana no veu: per exemple, crearComanda obté preus llegint la taula productes. No es pot redirigir "per ruta"; cal canviar el codi del monòlit. La tècnica:

1. Introduir una abstracció davant de la funcionalitat (una interfície RepositoriProductes).
2. Fer que el codi existent la faci servir (la implementació inicial continua llegint la taula).
3. Escriure una segona implementació que faci servir el servei nou (client HTTP de servei-cataleg).
4. Commutar entre totes dues amb configuració (una feature flag), primer en proves, després en producció, amb marxa enrere immediata si alguna cosa falla.
5. Esborrar la implementació antiga.

Fixa't que totes dues implementacions retornen la mateixa forma (producteId, nom, preu): aquesta forma és l'embrió del contracte del catàleg, i fer-la explícita dins del monòlit ja és un pas de descomposició encara que no s'hagi mogut ni una sola línia de servidor.

No tots els serveis s'extreuen alhora ni en qualsevol ordre. TechCorp puntua cada candidat en tres eixos:

• Valor: quant alleuja un problema real dels cinc de 01-05 (escalat en campanyes, desplegaments, incidents que es propaguen, model de dades forçat, equips que es trepitgen).
• Risc: quant negoci es posa en joc si l'extracció surt malament, i quanta lògica delicada (diners, identitat) es toca.
• Dependències: quantes àrees en depenen (entrants) i de quantes depèn (sortints). Poques dependències, extracció fàcil.

Tres raons resumeixen per què el catàleg va primer: és on hi ha el problema més car (les caigudes de campanya), és l'extracció amb menys risc (no toca diners ni el flux de comanda al seu camí crític) i no depèn de ningú: només Comandes en depèn per a dos camps, i això es resol amb l'abstracció de l'apartat 4.2. Extreure'l primer dona a més una victòria primerenca que justifica la inversió davant de la Marta i entrena l'equip de plataforma en el pipeline complet (Docker, Kubernetes, canary) amb el servei menys perillós.

I una raó per la qual comandes no va primer encara que sigui el core: extreure primer el servei que depèn de tots obligaria a construir sis contractes alhora o que servei-comandes continués llegint la base de dades del monòlit, és a dir, a néixer com a monòlit distribuït.

Tot monòlit té codi que "fa servir tothom". A techcorp-shop: bd/connexio.js, serveis/correu.js, serveis/passarellaPagament.js, a més d'utilitats menors (registre de logs, validació de peticions, format d'errors). Hi ha quatre destinacions possibles, i triar malament crea acoblament nou:

La regla que TechCorp adopta: es comparteix codi tècnic com a llibreria versionada; el codi de negoci no es comparteix, es converteix en un servei o es duplica conscientment. Duplicar un DTO de 5 camps en dos serveis és barat; compartir-lo costa l'autonomia de tots dos.

Apliquem tot l'anterior. El pla de descomposició de TechCorp:

Pas 1. Inventari del monòlit. Carpetes, mòduls i taules (01-05), i matriu taula × àrea (3.3).

Pas 2. Tall per capacitat de negoci, validat amb els grups d'esdeveniments de l'event storming (3.1) i amb la matriu de taules: sis capacitats, sis serveis. Coincideix amb les sis àrees funcionals, amb dos matisos que la matriu ha destapat: la reserva d'estoc la farà Inventari (avui la fa crearComanda) i el registre del pagament el farà Pagaments (avui el fa crearComanda).

Pas 3. Repartiment de codi i dades (les dades es detallen a 02-04; aquí, l'assignació):

Pas 4. Diagrama de dependències abans i després.

Abans: tots els mòduls depenen de totes les taules a través d'un únic pool de connexió. El graf és, a la pràctica, complet.

Després: cada servei depèn només del seu emmagatzematge; entre serveis només hi ha contractes (fletxes contínues: crides síncrones a l'API) i esdeveniments (fletxes discontínues: publicació/subscripció). El com d'aquestes fletxes és el mòdul 3.

Compara els dos grafs amb la taula d'acoblaments de 02-01: al primer, tot és acoblament de dades i de desplegament; al segon, només hi ha acoblament de contracte (dues crides síncrones de Comandes) i d'esdeveniments. Queda un acoblament temporal deliberat (Comandes consulta Catàleg i Clients de manera síncrona en crear la comanda); a 02-04 veurem l'alternativa de replicar aquestes dades i a 06-03 com protegir aquestes crides.

Pas 5. Ordre i tècnica d'extracció. Catàleg (strangler per rutes /productes + branch by abstraction per als preus a crearComanda), Inventari (branch by abstraction per a la reserva), Notificacions (el monòlit comença a publicar esdeveniments i el servei els consumeix), Pagaments (branch by abstraction per a passarellaPagament), Comandes (strangler de /comandes, ja amb la saga de 02-05) i Clients (strangler de /clients; el monòlit s'apaga).

• Tallar per carpetes del repositori. Les carpetes reflecteixen com es va organitzar el codi fa anys, no les costures de negoci. Fes servir la matriu de taules: no menteix.
• Refiar-se només del graf de require. En un monòlit amb BD compartida, l'acoblament és a l'SQL. Un mòdul sense dependències de codi pot escriure a quatre taules alienes.
• Extreure el core primer "perquè és l'important". És el que depèn de tots; extreure'l primer obliga a néixer acoblat. Comença pel que no depèn de ningú i aporta valor visible.
• Convertir les utilitats en una gran llibreria compartida. Cada actualització de la llibreria redesplega tothom: és acoblament de desplegament en estat pur. Només codi tècnic, versionat, i cada servei decideix quan actualitzar.
• Extreure sense façana. Sense gateway no hi ha strangler fig ni marxa enrere barata. El gateway és la primera peça, no l'última.
• Consell: abans de moure codi a un servei nou, arregla l'acoblament dins del monòlit (retorna les escriptures al seu propietari, introdueix les abstraccions). Un monòlit ben modularitzat es descompon en setmanes; un d'embolicat, en anys.

Amb la matriu taula × àrea de l'apartat 3.3: (a) quines dues taules exigeixen una refactorització dins del monòlit abans de poder extreure'n el servei, i en què consisteix? (b) Quina taula és la d'extracció més neta i per què? (c) Notificacions llegeix clients i comandes; com obtindrà aquestes dades quan sigui un servei, sense llegir taules alienes?

La Marta vol afegir "promocions" (cupons de descompte, el cas de 01-03) durant la migració. Aplica els criteris de valor, risc i dependències i decideix: es construeix directament com a servei-promocions o s'afegeix primer al monòlit? En quina posició de l'ordre d'extracció encaixaria? Justifica-ho en 5-8 línies.

Escriu l'esquelet (sense implementar detalls) de l'abstracció que permetria a crearComanda deixar d'escriure a estoc i passar a demanar la reserva a servei-inventari, amb commutació per configuració. Defineix el contracte de l'abstracció (nom del mètode, entrada, sortida) i indica què retornaria cada implementació quan no hi ha estoc.

Exercici 1

(a) estoc i pagaments: totes dues tenen dos escriptors. crearComanda reserva i descompta estoc, i insereix a pagaments. Abans d'extreure Inventari i Pagaments, cal moure aquesta lògica als seus mòduls propietaris dins del monòlit (per exemple, magatzem.reservar(...) i pagaments.registrarCobrament(...)), de manera que crearComanda només invoqui i no escrigui. Després, aquestes invocacions se substitueixen per crides al servei amb branch by abstraction. (b) atributs_producte (i notificacions): un sol escriptor, cap lector aliè. S'extreu amb Catàleg sense que ningú més se n'assabenti; a més, el seu model clau-valor és la raó per portar el catàleg a MongoDB. (c) Rebent-les a l'esdeveniment: comanda.confirmada inclourà el comandaId, el total i les dades mínimes del client necessàries per al correu (email, nom) que servei-comandes haurà obtingut per contracte de Clients. Alternativament, Notificacions podria consultar GET /clients/{id} en rebre l'esdeveniment; totes dues opcions es comparen a 02-04. El que no farà mai és SELECT sobre clients.

Exercici 2

Valor: mitjà-alt per a negoci (campanyes), però no resol cap dels cinc problemes de 01-05. Risc: baix en si mateix, però alt pel moment: afegir un servei nou mentre es migra el core duplica el front de treball. Dependències: promocions necessitaria conèixer productes (a què s'aplica) i comandes (on s'aplica), és a dir, depèn de dos serveis que encara no estan extrets. Decisió raonable: construir-lo dins del monòlit com un mòdul ben aïllat (la seva pròpia taula cupons, una abstracció Promocions.calcularDescompte(linies) que faci servir crearComanda), respectant des del primer dia els principis de 02-01 perquè la seva extracció posterior sigui trivial. Encaixaria en l'ordre entre Pagaments i Comandes (posició 4-5): després que existeixin Catàleg i Inventari (les seves dependències) i abans que Comandes s'extregui amb la saga definitiva, perquè el camp descompteAplicat de comanda.confirmada neixi ja al contracte. Si el negoci no ho necessita amb urgència, encara millor: després de Comandes, amb el sistema estable.

Exercici 3

L'essencial: les dues implementacions retornen la mateixa forma en èxit i en fallada ({ ok, reservaId } / { ok: false, motiu }), de manera que crearComanda no distingeix d'on ve la reserva; i l'abstracció ja inclou l'operació inversa (alliberar), perquè tan bon punt la reserva surti de la transacció única, caldran compensacions (02-05).

Descompondre un monòlit és una feina d'anàlisi abans que de codi. Hem vist les estratègies (capacitat de negoci com a base, subdominis de DDD com a refinament, substantius enfront de verbs per ajustar la granularitat, equips com a últim ajust), les tècniques per descobrir costures (event storming, graf de dependències del codi i, la més reveladora en un monòlit amb BD compartida, la matriu d'acoblament taula × àrea, que ha destapat que crearComanda escriu a estoc i pagaments sense ser-ne el propietari), les tècniques d'extracció segura (strangler fig darrere del gateway i branch by abstraction amb commutació per configuració) i els criteris d'ordre (valor, risc, dependències) que col·loquen el catàleg primer i comandes i clients al final. També hem decidit la destinació de les utilitats compartides: codi tècnic com a llibreria versionada; codi de negoci com a servei (correu.js → servei-notificacions, passarellaPagament.js → servei-pagaments) o duplicat a consciència. El resultat és el pla de TechCorp: sis serveis, cadascun amb els seus mòduls i les seves taules, i un graf de dependències que ha passat de "tots contra totes les taules" a "contractes i esdeveniments".

Aquest pla té encara les fronteres dibuixades a traç gruixut. La lliçó següent les afina amb DDD estratègic: definirem els bounded contexts de TechCorp, veurem per què "producte" i "client" no signifiquen el mateix a cada context, dibuixarem el mapa de contextos amb els seus patrons de relació i decidirem què és un agregat (i per què l'estoc no forma part de l'agregat Comanda).