El pla de descomposició de la lliçó anterior deixa sis serveis amb fronteres dibuixades a traç gruixut. Falta el que separa un disseny acceptable d'un de bo: decidir amb precisió on acaba el significat de cada paraula. Al monòlit de TechCorp, "producte" és una fila de la taula productes i tothom la fa servir; però el que el catàleg entén per producte (una fitxa amb descripció, imatges i atributs) no és el que entén inventari (un identificador amb quantitats) ni el que entén comandes (un nom i un preu congelats en el moment de la compra). Mentre les tres àrees compartien taula, l'ambigüitat es tolerava. Tan bon punt són serveis, l'ambigüitat es converteix en acoblament.

El Domain-Driven Design (DDD) en diu DDD estratègic i ofereix les eines per fer-ho bé: subdominis, llenguatge ubic, bounded contexts, mapa de contextos i agregats. Aquesta lliçó les aplica una per una a TechCorp: classificarem els subdominis, veurem exemples concrets d'ambigüitat, definirem els sis contextos i la seva relació amb els serveis, dibuixarem el mapa de contextos amb els seus patrons de relació, definirem l'agregat Comanda (i per què l'estoc no en forma part) i concretarem quins camps de "producte" i de "client" desa cada context. Com es materialitza això en bases de dades físiques separades és el tema de 02-04.

1. DDD estratègic en poques paraules
2. Els subdominis de TechCorp: core, suport i genèrics
3. Llenguatge ubic: quan "producte" i "client" no signifiquen el mateix
4. Què és un bounded context i com es relaciona amb un microservei
5. El mapa de contextos i els seus patrons de relació
6. Agregats i arrels d'agregat: la frontera transaccional
7. El model de dades de cada context

DDD (Eric Evans, 2003) té dues meitats. La tàctica parla de com escriure el codi d'un model (entitats, objectes de valor, repositoris, serveis de domini). L'estratègica parla de com dividir un problema gran en models que puguin evolucionar per separat. Per dissenyar microserveis, la meitat estratègica és la que importa, i es recolza en cinc idees:

La distinció que més confusió genera: subdomini és un tros del problema (existeix encara que no hi hagi programari); bounded context és un tros de la solució (un model que construïm). L'ideal és que coincideixin un a un, i a TechCorp així serà, però convé tenir clar que són coses diferents.

DDD classifica els subdominis segons el seu valor competitiu, i aquesta classificació dicta quant d'esforç de disseny mereix cadascun:

• Core (nucli): on l'empresa es diferencia. És el que cal dissenyar amb més cura i amb el millor equip, i el que mai no es compra fet.
• De suport: necessari per al negoci, específic de l'empresa, però no diferenciador. Es dissenya bé, sense obsessió.
• Genèric: un problema resolt igual a totes les empreses. Es compra, es fa servir un servei extern o s'implementa de la manera més senzilla possible.

Aquesta taula justifica decisions que ja vam prendre per intuïció: per què el catàleg i les comandes concentren la inversió, per què la identitat no apareix al mapa de serveis i per què Notificacions ha de ser avorrit.

El llenguatge ubic és el vocabulari que negoci i desenvolupament fan servir sense traducció, i que apareix tal qual al codi (per això els identificadors del curs són en català: crearComanda, ComandaRepositori, clientId). L'observació clau de DDD és que el llenguatge ubic només és coherent dins d'un context: la mateixa paraula canvia de significat en creuar la frontera, i pretendre un únic model "producte" per a tota l'empresa produeix un model gegant que no serveix bé a ningú (és la taula productes + atributs_producte de TechCorp).

La conseqüència pràctica més important és a la tercera fila: si el catàleg canvia el preu de p-501 demà, la comanda com-88213 d'avui no ha de canviar. Per això comandes desa una còpia congelada de nom i preu a linies_comanda, i per això l'esdeveniment "Preu canviat" de l'event storming de 02-02 no li interessa. No és duplicació accidental: és que són dos conceptes diferents que comparteixen identificador.

• "Estat": a Comandes, PENDENT / CONFIRMADA / CANCELLADA; a Pagaments, AUTORITZAT / CAPTURAT / REEMBORSAT; a Inventari, una reserva està ACTIVA / CONSUMIDA / ALLIBERADA. Tres màquines d'estats diferents que avui conviuen en columnes estat TEXT sense relació.
• "Cancel·lar": per a Comandes és tancar la comanda sense completar-la; per a Pagaments és no capturar un cobrament autoritzat; per a Inventari és alliberar una reserva. La saga de 02-05 encadenarà les tres, però cada context fa servir el seu verb.
• "Disponible": a Catàleg significa publicat; a Inventari significa quantitat - reservat > 0. Un producte pot estar disponible al catàleg i no a l'inventari, i a l'inrevés.

Detectar aquestes col·lisions és, a la pràctica, la manera més fiable de trobar fronteres: allà on una paraula canvia de significat, hi ha una costura.

Un bounded context és el límit explícit dins del qual un model de domini i el seu llenguatge ubic són coherents. A dins, "producte" significa una sola cosa; a fora, en pot significar una altra. Cada context té el seu propi model, el seu propi codi i (com veurem a 02-04) les seves pròpies dades.

La relació amb els microserveis:

La regla de TechCorp: un context, un servei, un equip propietari. I l'excepció admesa: durant la migració, el monòlit residual conté diversos contextos, cadascun al seu mòdul, amb les abstraccions de 02-02 marcant on són les fronteres.

Els contextos no viuen aïllats: Comandes necessita preus de Catàleg, Notificacions necessita saber que una comanda s'ha confirmat. El mapa de contextos dibuixa aquestes relacions i, sobretot, qui mana a cadascuna: en qualsevol relació hi ha un context upstream (aigües amunt: el seu model influeix) i un downstream (aigües avall: s'adapta o es protegeix). DDD cataloga els patrons de relació:

Aplicat a TechCorp:

Lectura relació per relació (U = upstream, D = downstream):

• Catàleg → Comandes: OHS + PL amb ACL a Comandes. Catàleg publica un contracte obert (GET /productes?ids=..., format JSON documentat) per a tots els consumidors (Comandes, la web, futurs serveis). Comandes no incorpora el model "fitxa de catàleg" al seu domini: una petita capa (traductorProducte) converteix { producteId, nom, preu, descripcio, atributs... } en l'única cosa que Comandes entén, una LiniaComanda amb nom i preu congelats. Així, si Catàleg canvia els seus atributs, Comandes no se n'assabenta.
• Clients → Comandes: Customer-Supplier. Comandes necessita saber que el client existeix i obtenir-ne l'email i l'adreça d'enviament. És una relació negociada: l'equip de Comandes pot demanar a Clients que exposi un GET /clients/{id} amb exactament aquests camps.
• Comandes ↔ Inventari: Partnership. Tots dos són de l'equip del Luis i evolucionen junts: Comandes publica comanda.creada, Inventari respon amb estoc.reservat (o la seva negativa). Els contractes d'aquests esdeveniments es dissenyen a la mateixa taula. Fixem-nos que Partnership no vol dir base de dades compartida: vol dir planificació compartida.
• Comandes → Pagaments → Comandes: Customer-Supplier per esdeveniments, amb PL. Pagaments consumeix estoc.reservat i publica pagament.confirmat (o el seu rebuig). El llenguatge publicat són els esquemes d'aquests esdeveniments.
• Comandes → Notificacions: Conformist. Notificacions accepta els esdeveniments de Comandes tal qual, sense demanar canvis: és un subdomini genèric i la seva feina és reaccionar. Si comanda.confirmada porta email i nom, els fa servir; no té cap model propi de client que protegir.
• Keycloak → Clients: Conformist. Keycloak és extern i estàndard (OpenID Connect); Clients s'adapta als seus tokens i desa l'identificador de Keycloak (sub) al costat del clientId.
• Passarel·la → Pagaments: ACL. La passarel·la té la seva pròpia API, els seus propis estats i els seus propis errors. servei-pagaments l'embolcalla en un adaptador (serveis/passarellaPagament.js, heretat del monòlit i ara en exclusiva) que tradueix als conceptes de Pagaments: AUTORITZAT, CAPTURAT, REBUTJAT, REEMBORSAT. Canviar de passarel·la només toca aquesta capa.
• Shared Kernel: cap, per decisió. La temptació seria compartir "identificadors", "diners" o "el sobre dels esdeveniments" com a llibreria comuna de domini. TechCorp ho evita: els identificadors són cadenes opaques i el format del sobre d'esdeveniments és llenguatge publicat (documentat), no codi compartit. És la mateixa regla de 02-02 sobre utilitats compartides.
• Separate Ways: Catàleg i Notificacions, Inventari i Clients. No es parlen. Si Notificacions algun dia necessités el nom d'un producte per a un correu, el rebria a l'esdeveniment abans que integrar-se amb Catàleg.

Baixem un nivell. Dins d'un context, el model s'organitza en agregats: grups d'objectes que es tracten com una unitat per als canvis d'estat. Cada agregat té una arrel (l'única entitat a la qual s'accedeix des de fora) i defineix una frontera de consistència: els invariants (regles que sempre s'han de complir) es garanteixen dins de l'agregat, en una única transacció; entre agregats, la consistència és eventual.

Regles pràctiques de disseny d'agregats:

1. Una transacció modifica un sol agregat. Si en necessites modificar dos, o el disseny està malament o toca acceptar consistència eventual entre ells (02-05).
2. Els agregats es referencien per identificador, mai per objecte: una Comanda desa clientId, no un objecte Client.
3. Agregats petits. Un agregat gran bloqueja molt i escala malament.
4. L'arrel protegeix els invariants. Ningú no modifica una línia de comanda "per fora"; es demana a la Comanda que l'afegeixi, i la Comanda comprova que pot.

En el context Comandes, l'agregat és Comanda (arrel) amb les seves LíniaComanda (entitats internes) i la seva AdreçaEnviament (objecte de valor, còpia). Els seus invariants:

• El total és sempre la suma de preuUnitari × quantitat de les seves línies.
• Una comanda té com a mínim una línia i cap línia no té quantitat ≤ 0.
• Una comanda CONFIRMADA o CANCELLADA no admet canvis de línies.
• Les transicions d'estat segueixen la màquina d'estats que veurem a 02-05.

Què no hi ha en aquest agregat, i per què:

• No hi ha estoc. L'invariant "no reservar més del que hi ha" (quantitat - reservat >= 0) pertany al context Inventari i al seu agregat (una Reserva associada a un comandaId, o el mateix Estoc per producte). Ficar l'estoc a la Comanda tindria tres problemes: (1) la Comanda hauria de conèixer un invariant que no és seu; (2) una fila d'estoc la toquen centenars de comandes concurrents, així que l'agregat Comanda "abastaria" files compartides per totes les comandes i les transaccions es bloquejarien entre si (exactament el que passava a crearComanda amb la passarel·la dins de la transacció); (3) l'estoc canvia per motius aliens a la comanda (entrades de magatzem, minves). Per això, en el disseny objectiu, Comandes demana la reserva i la resposta arriba com a esdeveniment.
• No hi ha objecte Client ni objecte Producte. Només clientId i producteId, més les còpies de valor (adreça, nom, preu) que la comanda necessita per ser autosuficient.
• No hi ha pagament. El Pagament és agregat d'un altre context; la Comanda només sap que el seu estat va passar a PAGADA quan va arribar l'esdeveniment.

I als altres contextos, els agregats principals:

Concretem què desa cada context dels conceptes compartits. Encara no parlem de bases de dades físiques (02-04), sinó de quins camps existeixen a cada model.

Exemple del mateix producte vist des de cada context (format il·lustratiu; l'esquema físic arriba a 02-04):

És la mateixa estructura que retornava GET /comandes/{id} a 01-01, ara explicada: tot el que hi ha a dins és del context Comandes (referències per id + còpies de valor); res del que hi ha a dins no obliga a consultar un altre context per llegir la comanda.

• Buscar el "model canònic" de producte per a tota l'empresa. És el camí de tornada a la taula productes + atributs_producte. Cada context té el seu producte; comparteixen identificador, no model.
• Confondre bounded context amb mòdul tècnic. "Context de persistència" o "context d'API" no són bounded contexts: no tenen llenguatge de negoci propi.
• Agregats enormes. Una Comanda que conté el Client, els Productes i l'Estoc "per tenir-ho tot a mà" bloqueja mitja empresa a cada transacció. Referències per id i còpies de valor.
• Copiar dades "per si de cas" en lloc de per semàntica. Comandes copia nom i preu perquè el negoci diu que la comanda conserva el preu de la compra, no per rendiment. Si copies alguna cosa que semànticament ha d'estar sempre actualitzada (per exemple, l'email per contactar), tindràs dades obsoletes; aquí toca consultar o subscriure's als canvis (02-04).
• Ignorar l'ACL amb sistemes externs. Deixar que els estats de la passarel·la de pagament es filtrin al model de Pagaments (i d'aquí als esdeveniments) fa que canviar de passarel·la sigui un canvi a tota l'empresa.
• Consell: mantén un glossari per context (una taula: terme, significat en aquest context, camp al codi). Quan dos glossaris discrepin sobre una paraula, no ho resolguis: és una frontera confirmada.

TechCorp estudia afegir dues capacitats: (a) valoracions de productes pels clients (estrelles i comentaris a la fitxa) i (b) facturació (emissió de factures legals per cada comanda confirmada). Per a cadascuna: classifica-la com a core, suport o genèrica; indica de quins contextos existents seria downstream i quin patró de relació faries servir amb cadascun.

En una reunió, l'equip d'Inventari diu "el producte p-501 no està disponible" i l'equip de Catàleg respon "sí que ho està, el vaig publicar ahir". Explica l'ambigüitat amb el vocabulari d'aquesta lliçó, indica com la resoldries als contractes (quin camp exposa cada context) i què hauria de mostrar la web al client en aquest cas.

Per a cada element, decideix si forma part de l'agregat Comanda, és un agregat propi del context Comandes, o pertany a un altre context, i justifica-ho amb la regla dels invariants: (1) el cupó de descompte aplicat a una comanda; (2) l'historial de canvis d'estat de la comanda; (3) la valoració que el client deixa de la comanda després de rebre-la; (4) la reserva d'estoc de la comanda.

Exercici 1

(a) Valoracions: subdomini de suport (aporta a l'experiència, però no és el nucli de venda ni un problema genèric). Seria downstream de Catàleg (necessita saber que el producte existeix: OHS + PL, consumint el contracte públic) i de Comandes o Clients per verificar que qui valora va comprar el producte (Customer-Supplier: demanaria un GET /comandes?clientId=...&producteId=... o un esdeveniment comanda.lliurada). El seu model de "producte" seria mínim: producteId i nom per mostrar. Podria viure dins del context Catàleg si és molt simple; com a servei propi si el volum d'escriptura o l'equip ho justifiquen. (b) Facturació: subdomini de suport amb un fort component genèric (les regles fiscals són iguals per a tothom; moltes empreses fan servir un proveïdor). Downstream de Comandes (Conformist o Customer-Supplier sobre comanda.confirmada, del qual necessita línies, imports i impostos) i de Clients (dades fiscals: Customer-Supplier, demanant un camp dadesFiscals). Si es fa servir un proveïdor extern de facturació, ACL davant de la seva API. Mai no compartiria taules amb Comandes encara que "gairebé tot el que necessita és a comandes".

Exercici 2

"Disponible" té dos significats: a Catàleg, publicat (la fitxa es mostra); a Inventari, amb unitats lliures (quantitat - reservat > 0). Tots dos tenen raó en el seu context. Als contractes, cadascun exposa el seu concepte amb el seu nom: Catàleg, publicat: true/false; Inventari, disponible: 113 (unitats lliures) o hiHaEstoc: true/false. La web (o un BFF, 03-04) compon tots dos: mostra la fitxa perquè està publicada i el botó "comprar" desactivat amb el text "sense estoc" perquè Inventari diu 0. El que no s'ha de fer és afegir a la fitxa del catàleg un camp estoc mantingut a mà: és una dada d'un altre context (si es mostra, s'obté per contracte o per rèplica d'esdeveniments, 02-04).

Exercici 3

1. Cupó aplicat: dins de l'agregat Comanda com a dada de valor (descompteAplicat, codi i quantitat), perquè afecta l'invariant del total; la definició del cupó (validesa, condicions) és d'un altre context (Promocions), referenciat per codi.
2. Historial d'estats: pot formar part de l'agregat (llista de transicions amb data) si és petit i es fa servir per validar transicions; si creix o només serveix per a auditoria, agregat propi o simplement un registre d'esdeveniments del context Comandes. En cap cas un altre context.
3. Valoració de la comanda: fora de l'agregat i probablement fora del context: no afecta cap invariant de la comanda i té cicle de vida propi (arriba dies després, es pot editar). Referència per comandaId.
4. Reserva d'estoc: un altre context (Inventari), agregat Reserva amb comandaId. El seu invariant (quantitat - reservat >= 0) no és de la Comanda, i ficar-la a dins faria que cada comanda bloquegés files compartides per totes.

Amb DDD estratègic hem convertit les sis àrees de TechCorp en sis bounded contexts ben definits: hem classificat els seus subdominis (Comandes i Catàleg com a core; Inventari, Clients i Pagaments de suport; Notificacions i Identitat genèrics, aquesta última delegada a Keycloak), hem comprovat que "producte", "client", "estat", "cancel·lar" i "disponible" signifiquen coses diferents a cada context i que aquesta diferència marca les costures, hem dibuixat el mapa de contextos amb els seus patrons (Catàleg com a OHS + PL amb ACL a Comandes; Clients → Comandes com a Customer-Supplier; Comandes ↔ Inventari com a Partnership; Comandes → Notificacions com a Conformist; ACL davant de la passarel·la; sense shared kernel per decisió) i hem definit l'agregat Comanda amb les seves línies i la seva adreça congelada, deixant fora l'estoc, el client i el pagament per raons d'invariants i contenció. Finalment, hem fixat quins camps desa cada context dels conceptes compartits: el catàleg té la fitxa completa; inventari, producteId i quantitats; comandes, còpies congelades de nom i preu a les seves línies.

Tot això continua sent model. La lliçó següent ho fa físic: una base de dades per servei. Veurem per què la base de dades compartida és l'antipatró principal, com es trenquen les claus foranes creuades de l'esquema de 01-05 (comandes.client_id, linies_comanda.producte_id), quines alternatives hi ha per a les consultes que avui són un JOIN, com es migren les dades sense aturar la botiga i quin esquema concret tindrà cada servei, inclòs el catàleg a MongoDB.