La decisió més difícil en dissenyar una arquitectura de microserveis no és la tecnologia, sinó on traçar les fronteres: què entra a cada servei i què queda fora. Una mala descomposició provoca serveis acoblats que cal desplegar junts, esquemes de dades compartits i canvis que es propaguen en cascada. Una bona descomposició produeix serveis cohesius, autònoms i fàcils d'evolucionar.
En aquesta lliçó estudiarem les dues estratègies principals de descomposició (per capacitat de negoci i per subdomini), introduirem el concepte de bounded context del Disseny Guiat pel Domini (DDD) i aprendrem a calibrar la mida i la granularitat adequades d'un servei.
Contingut
- El problema de les fronteres
- Estratègia 1: descomposició per capacitat de negoci
- Estratègia 2: descomposició per subdomini (DDD)
- Bounded Contexts i llenguatge ubic
- Granularitat i mida adequada
- Acoblament, cohesió i el mapa de contextos
- Errors comuns i consells
- Exercicis
- Conclusió
- El problema de les fronteres
Una frontera mal posada té un cost enorme: corregir-la implica moure dades, reescriure APIs i coordinar diversos equips. L'objectiu d'una bona frontera és maximitzar la cohesió dins del servei (les coses que canvien juntes estan juntes) i minimitzar l'acoblament entre serveis (canviar-ne un no obliga a canviar-ne d'altres).
| Propietat | Què busquem |
|---|---|
| Cohesió | Alta: allò que canvia junt, viu junt. |
| Acoblament | Baix: els serveis depenen poc els uns dels altres. |
| Autonomia | Alta: cada servei es desplega i opera sol. |
La regla d'or: descompon per domini de negoci, no per capa tècnica. Serveis com ara "servei de base de dades", "servei de validacions" o "servei d'utilitats" són un antipatró, perquè cap canvi de negoci es resol tocant un sol servei.
- Estratègia 1: descomposició per capacitat de negoci
Una capacitat de negoci és una cosa que l'organització fa per generar valor, independentment de com ho implementi. S'identifiquen analitzant què fa l'empresa, no quines taules té.
En una asseguradora, capacitats típiques serien:
- Gestió de clients
- Contractació de pòlisses
- Tramitació de sinistres
- Facturació i cobraments
- Reassegurança
# Cada capacitat de negoci es converteix en un candidat a servei
capacidades:
contratacion_polizas:
acciones: [crear_poliza, renovar_poliza, anular_poliza]
eventos_publicados: [PolizaCreada, PolizaRenovada, PolizaAnulada]
tramitacion_siniestros:
acciones: [abrir_siniestro, peritar, indemnizar]
eventos_publicados: [SiniestroAbierto, SiniestroIndemnizado]Cada capacitat agrupa les accions i els esdeveniments que li pertanyen. Aquesta estratègia és estable, perquè les capacitats de negoci canvien molt menys sovint que la tecnologia.
- Estratègia 2: descomposició per subdomini (DDD)
El Disseny Guiat pel Domini descompon el domini total en subdominis, que classifica en tres tipus:
| Tipus de subdomini | Definició | Estratègia recomanada |
|---|---|---|
| Nucli (core) | Allò que diferencia l'empresa; el seu avantatge competitiu. | Invertir-hi el millor esforç; desenvolupament propi acurat. |
| De suport (supporting) | Necessari però no diferenciador. | Desenvolupament més senzill, possible externalització parcial. |
| Genèric (generic) | Problema comú ja resolt al mercat. | Comprar o usar solució estàndard. |
Per a una asseguradora, el càlcul actuarial de primes és probablement un subdomini nucli; la gestió documental és de suport; i l'enviament de correus electrònics és genèric (s'usa un proveïdor extern).
Aquesta classificació guia les inversions: no té sentit construir des de zero un subdomini genèric quan existeixen solucions madures.
- Bounded Contexts i llenguatge ubic
Un bounded context (context delimitat) és una frontera explícita dins de la qual un model del domini i el seu vocabulari tenen un significat precís i únic. La idea central és que la mateixa paraula pot significar coses diferents en contextos diferents.
Considera el terme "Client":
- A Contractació, un client és un prenedor amb capacitat de contractar i un perfil de risc.
- A Facturació, un client és un deutor amb un compte i uns rebuts.
- A Sinistres, un client és un perjudicat o beneficiari.
Forçar un únic model de "Client" per als tres contextos produeix una classe gegantina amb desenes de camps que ningú no entén del tot. La solució del DDD és que cada bounded context tingui el seu propi model de Client, adaptat a les seves necessitats.
// Mateix concepte, dos models segons el bounded context.
// Context Contractació: ens importa el risc
package com.fiatc.contratacion;
public class Cliente {
private String id;
private PerfilRiesgo perfilRiesgo;
private List<Poliza> polizasVigentes;
}
// Context Facturació: ens importen els cobraments
package com.fiatc.facturacion;
public class Cliente {
private String id; // mateix identificador per correlacionar
private FormaPago formaPago;
private List<Recibo> recibosPendientes;
}L'id actua com a nexe entre contextos, però cada model només conté allò que el seu domini necessita. El llenguatge ubic és el vocabulari comú que comparteixen desenvolupadors i experts de negoci dins d'un context, i que es reflecteix directament en el codi.
graph LR
subgraph "Context Contractació"
C1[Client: prenedor]
end
subgraph "Context Facturació"
C2[Client: deutor]
end
subgraph "Context Sinistres"
C3[Client: beneficiari]
end
C1 -. mateix id .- C2
C2 -. mateix id .- C3Cada bounded context és un candidat natural a microservei. Aquesta és la regla més fiable per traçar fronteres.
- Granularitat i mida adequada
Com de gran ha de ser un servei? No hi ha una mètrica màgica de línies de codi. Millors indicadors:
- Cohesió funcional: un servei ha de poder descriure's amb una frase de negoci.
- Transaccionalitat: allò que necessita estar en una mateixa transacció ACID hauria de viure en el mateix servei.
- Ritme de canvi: allò que canvia junt ha d'estar junt.
- Autonomia de l'equip: un servei cap al cap d'un equip petit.
| Símptoma | Diagnòstic | Acció |
|---|---|---|
| Moltes crides entre dos serveis per a cada operació | Massa fragmentat | Fusionar |
| Per a un canvi de negoci cal tocar 5 serveis | Fronteres mal posades | Redissenyar fronteres |
| Un servei amb desenes de responsabilitats dispars | Massa gran | Dividir |
| Necessites transaccions distribuïdes constantment | Divisió incorrecta | Reagrupar per consistència |
El consell pràctic: comença amb serveis més grans del que creus necessari i divideix-los quan aparegui dolor real. És molt més fàcil dividir un servei que fusionar-ne dos.
- Acoblament, cohesió i el mapa de contextos
El DDD proposa documentar com es relacionen els contextos mitjançant un mapa de contextos. Alguns patrons de relació:
- Client/Proveïdor: un context consumeix l'API d'un altre; el proveïdor ha de respectar les necessitats del client.
- Conformista: el consumidor s'adapta sense més al model del proveïdor.
- Capa anticorrupció (ACL): el consumidor tradueix el model aliè al seu propi per no contaminar-se.
// Capa anticorrupció: tradueix el model extern al model intern
public class ClienteAcl {
public Cliente traducir(ClienteExternoDTO dto) {
// No deixem que el model extern "s'esmunyi" al nostre domini
Cliente cliente = new Cliente();
cliente.setId(dto.getCodigo()); // mapatge de noms
cliente.setPerfilRiesgo(calcular(dto)); // adaptació de semàntica
return cliente;
}
}La capa anticorrupció és valuosíssima en integrar sistemes heretats: aïlla el teu model net de les raresa del sistema extern.
Errors Comuns i Consells
- Descompondre per capes tècniques (dades, validació, lògica): qualsevol canvi de negoci toca tots els serveis. Descompon per domini.
- Un únic model canònic per a tota l'empresa: produeix models gegants i inmanejables. Adopta bounded contexts.
- Serveis massa petits des del principi: comença gran i divideix davant el dolor real.
- Ignorar els experts de negoci: les fronteres correctes sorgeixen de converses amb qui coneix el domini (tècniques com l'Event Storming ajuden).
- Compartir taules entre contextos: trenca la frontera. Usa APIs o esdeveniments.
Exercicis
- Explica amb les teves paraules què és un bounded context i per què la mateixa paraula ("Compte", "Producte"...) pot necessitar models diferents en contextos diferents.
- Classifica els següents subdominis d'un banc en nucli, de suport o genèric, i justifica-ho: (a) motor de scoring creditici, (b) gestió de plantilles de documents, (c) enviament d'SMS.
- Et trobes dos serveis, "Comandes" i "Línies de comanda", que es criden mútuament desenes de vegades per operació i comparteixen transaccions. Quin diagnòstic fas i quina acció prens?
Solucions
-
Un bounded context és una frontera dins de la qual un model i el seu vocabulari tenen un significat únic i coherent. La mateixa paraula necessita models diferents perquè cada context s'interessa per atributs i comportaments diferents: "Producte" al catàleg porta descripció i imatges, mentre que al magatzem porta ubicació i estoc. Unificar-los crea un model sobrecarregat.
-
(a) Nucli: l'scoring diferencia el banc i és el seu avantatge competitiu; desenvolupament propi acurat. (b) Suport: necessari però no diferenciador; desenvolupament senzill. (c) Genèric: problema resolt; es contracta un proveïdor d'SMS.
-
Diagnòstic: estan massa fragmentats; la fragmentació creua una frontera transaccional. Acció: fusionar-los en un únic servei "Comandes" que contingui les línies com a part del seu agregat, eliminant les crides de xarxa i permetent transaccions ACID locals.
Conclusió
Hem vist que la clau d'una bona arquitectura de microserveis rau a traçar fronteres per domini de negoci, recolzant-nos en les capacitats de negoci i, sobretot, en els bounded contexts del DDD. La granularitat correcta busca alta cohesió i baix acoblament, i convé començar amb serveis grans i dividir davant el dolor real.
Un cop definits els serveis i les seves fronteres, sorgeix la pregunta pràctica de com es parlen entre si sense acoblar-se en excés. La lliçó següent, API Gateway, Service Discovery i Comunicació entre Serveis, aborda precisament els mecanismes de comunicació síncrona i asíncrona, i la infraestructura que els fa possibles.
Curs d'Arquitectura d'Aplicacions
Mòdul 1: Fonaments de l'Arquitectura d'Aplicacions
- Què és l'Arquitectura d'Aplicacions?
- El Rol de l'Arquitecte de Programari
- Atributs de Qualitat i Requisits No Funcionals
- Decisions Arquitectòniques i Compromisos (Trade-offs)
- Documentació d'Arquitectura: Vistes i el Model C4
Mòdul 2: Principis i Tàctiques de Disseny
- Acoblament, Cohesió i Separació de Responsabilitats
- Principis SOLID Aplicats a l'Arquitectura
- DRY, KISS, YAGNI i Altres Principis de Disseny
- Tàctiques Arquitectòniques per als Atributs de Qualitat
- Gestió del Deute Tècnic
Mòdul 3: Estils i Patrons Arquitectònics
- Arquitectura Monolítica
- Arquitectura en Capes (N-Tier)
- Arquitectura Client-Servidor
- Arquitectura Hexagonal (Ports i Adaptadors)
- Arquitectura Neta i Ceba (Clean & Onion)
Mòdul 4: Arquitectures Distribuïdes i Microserveis
- Introducció als Sistemes Distribuïts
- Arquitectura de Microserveis
- Descomposició de Serveis i Bounded Contexts
- API Gateway, Service Discovery i Comunicació entre Serveis
- Patrons de Resiliència: Circuit Breaker, Retry i Bulkhead
- El Teorema CAP i la Consistència de Dades
Mòdul 5: Arquitectures Dirigides per Esdeveniments i Missatgeria
- Fonaments de l'Arquitectura Orientada a Esdeveniments
- Missatgeria Asíncrona: Cues i Brokers
- Patrons d'Esdeveniments: Event Sourcing i CQRS
- Gestió de Transaccions Distribuïdes: Patró Saga
- Streaming de Dades en Temps Real
Mòdul 6: Disseny Dirigit pel Domini (DDD)
- Conceptes Fonamentals del DDD
- Disseny Estratègic: Bounded Contexts i Llenguatge Ubic
- Disseny Tàctic: Entitats, Agregats i Repositoris
- Mapatge de Contextos (Context Mapping)
Mòdul 7: Dades i Persistència
- Estratègies de Persistència: SQL vs NoSQL
- Patrons d'Accés a Dades: Repository, Unit of Work i DAO
- Base de Dades per Servei i Gestió de Dades Distribuïdes
- Cau i Estratègies d'Invalidació
Mòdul 8: Arquitectura al Núvol i Desplegament
- Fonaments del Cloud Computing (IaaS, PaaS, SaaS)
- Contenidors i Orquestració amb Docker i Kubernetes
- Arquitectura Serverless
- Patrons de Disseny Cloud-Native
- Infraestructura com a Codi (IaC)
Mòdul 9: Qualitat, Seguretat i Observabilitat
- Escalabilitat: Horitzontal vs Vertical i Balanceig de Càrrega
- Alta Disponibilitat i Tolerància a Fallades
- Seguretat per Disseny i Autenticació/Autorització
- Observabilitat: Logging, Mètriques i Traçabilitat
- Rendiment i Proves de Càrrega