El disseny estratègic és la part del DDD que decideix com dividir un domini gran en peces manejables i coherents. A la lliçó anterior vam aprendre a classificar subdominis; ara traçarem els límits concrets del model dins del programari mitjançant el concepte més important de tot el DDD: el Bounded Context (context delimitat). Al costat d'ell estudiarem el Llenguatge Ubic, el vocabulari compartit que manté alineats negoci i desenvolupament. Aquesta lliçó és important perquè és on el DDD connecta directament amb l'arquitectura: els límits que tracem aquí determinaran, per exemple, les fronteres dels nostres microserveis. Equivocar-se en aquests límits és una de les causes més cares de fracàs en sistemes distribuïts.

1. El problema: un mateix terme, significats diferents
2. Llenguatge Ubic
3. Bounded Context (context delimitat)
4. Relació entre Bounded Contexts i microserveis
5. Exemple integrat en una asseguradora

En qualsevol organització mitjana, les mateixes paraules signifiquen coses diferents segons el departament. Pensem en la paraula "Client" en una asseguradora:

• Per a l'àrea Comercial, un Client és un lead amb dades de contacte i un historial d'interaccions de venda.
• Per a l'àrea de Subscripció, un Client és un perfil de risc amb edat, professió i sinistralitat prèvia.
• Per a l'àrea de Facturació, un Client és un compte amb domiciliació bancària, rebuts i deutes.

Si intentem crear una única classe Cliente gegant que serveixi a tothom, obtenim un objecte enorme, ple de camps que només alguns utilitzen, amb regles contradictòries i que ningú pot modificar sense por de trencar una altra àrea. Aquest és el clàssic "model únic per a tota l'empresa", i sempre fracassa en dominis complexos.

El DDD proposa el contrari: acceptar que el significat depèn del context i traçar límits explícits.

El Llenguatge Ubic (Ubiquitous Language) és un vocabulari comú, rigorós i compartit entre desenvolupadors i experts del domini, que s'usa a tot arreu: a les converses, a la documentació i —crucialment— al codi.

Principis:

• Cada terme té un significat únic i precís dins del seu context.
• Si el negoci diu "subscriure una pòlissa", el codi té un mètode suscribir(), no create() ni save().
• El llenguatge evoluciona: quan es descobreix un matís, s'actualitzen alhora el llenguatge parlat i el codi.

Vegem la diferència que produeix en el codi:

Problemes del fragment anterior:

• PolicyManager, process i update no diuen res del negoci. Què processa? Què actualitza?
• L'estat es representa amb un int: ningú sap què significa status = 2.
• Un expert del domini no podria llegir aquest codi ni validar que fa el correcte.

Aquí:

• Els noms suscribir, rechazarPorRiesgoExcesivo i renovar són exactament els verbs que usa el negoci.
• Els tipus Suscriptor i MotivoRechazo són conceptes del domini, no dades primitives soltes.
• Un expert del domini pot llegir i entendre què fa la classe, cosa que permet detectar errors de modelatge en conversa, sense executar res.

El Llenguatge Ubic és el pont que elimina la traducció constant entre "el que diu el negoci" i "el que escriu el programador".

Un Bounded Context és una frontera explícita dins de la qual un model de domini i el seu Llenguatge Ubic tenen un significat únic i consistent. Fora d'aquesta frontera, els mateixos termes poden significar una cosa diferent, i això està bé.

Cada Bounded Context té:

• El seu propi model de domini.
• El seu propi Llenguatge Ubic (la paraula "Client" es pot modelar de manera diferent en cadascun).
• Les seves pròpies regles de negoci i, normalment, la seva pròpia base de dades.

Tornant a l'exemple del "Client":

La idea radical és: no existeix un únic "Client". Existeixen tres models diferents, cadascun òptim per al seu context, que comparteixen una identitat referenciada (un identificador comú) però no la mateixa estructura. Com es comuniquen aquests contextos ho veurem a la lliçó 06-04 (Context Mapping).

Sobre aquest diagrama Mermaid (graph LR, d'esquerra a dreta):

• Cada subgraph representa un Bounded Context amb la seva frontera explícita.
• Dins de cada context viu un model diferent del "client": Lead, Assegurat, CompteDeClient.
• Les fletxes puntejades (-.->) indiquen que es refereixen a la mateixa persona real, però no comparteixen el mateix model de codi: estan connectades per identitat, no per estructura.

Existeix una correspondència natural —però no obligatòria— entre els Bounded Contexts i els microserveis:

La bona pràctica és: un microservei hauria de contenir un o diversos Bounded Contexts complets, mai partir un Bounded Context entre diversos microserveis. Si parteixes un context, reparteixes el seu model i les seves regles entre serveis diferents, cosa que genera un acoblament fortíssim i comunicació constant.

Els Bounded Contexts ofereixen el criteri de descomposició que els equips de microserveis solen trobar a faltar. Sense DDD, molts parteixen els serveis per entitats tècniques ("servei d'usuaris", "servei de comandes") i acaben amb un monòlit distribuït.

Exemple de com un Bounded Context es tradueix en la configuració d'un microservei independent:

Comentaris sobre aquest YAML de Kubernetes:

• name: suscripcion-service deixa clar que el servei correspon a un únic Bounded Context (Subscripció).
• image referencia la imatge de contenidor d'aquest context, versionada de manera independent.
• La variable DB_URL apunta a db-suscripcion: una base de dades pròpia i exclusiva del context. Altres contextos no hi accedeixen directament; això preserva la frontera.

Posem-ho tot junt. Una asseguradora podria organitzar el seu sistema en aquests Bounded Contexts:

Lectura del diagrama:

• Vendes capta interessats; quan un accepta, passa a Subscripció.
• Subscripció avalua el risc i, si l'aprova, Gestió de Pòlisses crea la pòlissa.
• Gestió de Sinistres i Facturació depenen de la pòlissa vigent.

Cadascun d'aquests contextos té el seu propi Llenguatge Ubic: a Vendes es parla de "Lead" i "oportunitat"; a Sinistres, de "comunicat", "perit" i "indemnització". Forçar un vocabulari únic entre tots ells seria un error.

• El model únic corporatiu. Intentar que una sola classe Cliente o Producto serveixi a tota l'empresa. Resultat: un objecte inmanejable. Accepta la multiplicitat de models.
• Bounded Contexts massa petits. Si cada entitat és el seu propi context, tindràs centenars de serveis diminuts parlant entre si sense parar. El context ha de ser cohesionat, no atòmic.
• Confondre frontera lògica amb frontera física. Un Bounded Context és un concepte lògic del DDD; un microservei és una decisió de desplegament. Pots començar amb diversos contextos dins d'un mateix monòlit (un monòlit modular) i separar-los en serveis només quan calgui.
• No mantenir viu el Llenguatge Ubic. Si el negoci canvia un terme i el codi no, el pont es trenca. Refactoritza els noms quan canviï el llenguatge.
• Consell: organitza els teus paquets Java per Bounded Context (com.fiatc.suscripcion, com.fiatc.siniestros), no per capa tècnica (controllers, services). El paquet ha de cridar el domini.

Exercici 1. Tria el terme "Producte" en una botiga en línia i descriu com el modelaries de manera diferent en com a mínim dos Bounded Contexts (per exemple, Catàleg i Inventari).

Exercici 2. Reescriu la següent signatura de mètode aplicant el Llenguatge Ubic del domini de sinistres: void update(Long id, int type, String text).

Exercici 3. Un equip ha dividit el seu sistema en "servei-base-de-dades", "servei-lògica" i "servei-frontend". Explica per què aquesta divisió no es correspon amb Bounded Contexts i proposa una alternativa.

Solució 1. En el context de Catàleg, un Producte és contingut de màrqueting: nom, descripció, fotos, preu de venda, categories. En el context d'Inventari, el mateix producte és una ReferenciaDeStock: SKU, unitats disponibles, ubicació al magatzem, punt de reposició. Comparteixen l'identificador del producte, però els seus atributs i regles són diferents.

Solució 2. Una possible reescriptura: void registrarParteDeSiniestro(IdSiniestro id, TipoSiniestro tipo, DescripcionDanos descripcion). Els noms reflecteixen els conceptes del negoci i els tipus substitueixen els primitius genèrics.

Solució 3. Aquesta divisió és tècnica per capes, no per domini: cada "servei" necessita els altres per fer qualsevol cosa, cosa que produeix un acoblament total i comunicació constant (un monòlit distribuït). Una alternativa basada en Bounded Contexts seria dividir per capacitats de negoci —per exemple, "Subscripció", "Pòlisses", "Sinistres"— on cada servei conté la seva pròpia lògica, dades i interfície de la seva part del domini.

Hem vist que el disseny estratègic tracta de traçar fronteres: el Llenguatge Ubic garanteix que negoci i codi parlin el mateix idioma, i el Bounded Context delimita l'abast dins del qual aquest idioma i el seu model són consistents. Hem comprovat que un mateix concepte del món real ("Client", "Producte") es modela de manera diferent en cada context, i que aquests contextos són els millors candidats per definir les fronteres dels microserveis, evitant el temut monòlit distribuït.

A la lliçó següent, "Disseny Tàctic: Entitats, Agregats i Repositoris", baixarem del mapa estratègic al detall d'implementació: veurem amb codi Java com construir el model ric dins d'un Bounded Context usant els patrons tàctics del DDD.