Un marketplace B2B efficace nasce da scelte architetturali nette. Le imprese chiedono integrazioni fluide, tempi di risposta rapidi e conformità cross-border. Senza una base modulare, ogni nuova feature rallenta tutto il sistema. Questo tutorial traduce principi tecnici in decisioni operative: dal perimetro dei domini ai contratti API dai pattern event-driven ai criteri per scalare in più Paesi.
L’obiettivo è mettere al centro evolvibilità e isolare la complessità: bounded context chiari, microservizi indipendenti, orchestrazione minima e visibilità end-to-end. Con una checklist di readiness, il percorso passa da teoria a piano d’azione, riducendo rischi nel go-live e nei rollout geografici.
Domini chiari e confini netti: il perimetro che evita il caos
La mappa dei domini è il primo investimento. Definire core domain e supporting domain evita dipendenze tossiche. Un marketplace tipico separa: Catalogo (schede, attributi, classificazioni), Prezzi & Promozioni (listini, sconti, regole), Ordini (checkout, stato, fulfillment), Pagamenti (escrow, riconciliazione), Logistica (spedizioni, tracciamento), Compliance (fiscale, KYC, audit), Identità & Accessi (ruoli, SSO). Ogni ambito diventa un bounded context con model e regole proprie. La strategia consigliata: limitare i coupling a eventi di dominio, vietare letture dirette di database tra servizi e orchestrare solo dove la consistenza forte è obbligatoria.
Servizi e microservizi: mappatura, responsabilità e contratti API
Per ogni dominio, un servizio con responsabilità unica. Il Catalogo pubblica API per ricerca e arricchimento dati; Ordini espone comandi e query sul ciclo di vita; Pagamenti gestisce autorizzazioni e settlement. La regola: evitare servizi anemici o “tuttofare”. I contratti API seguono versioning semantico, rate limit e idempotenza per i comandi. Payload compatti (JSON/Protobuf), paginazione deterministica e schema registry per compatibilità. I flussi sincroni coprono validazioni critiche e UX; il resto viene delegato a eventi asincroni. Documentazione con OpenAPI, test di contratto e backward compatibility rigorosa riducono regressioni.
Event-driven con saghe: coreografia dove serve, orchestrazione dove conta
Un bus eventi o stream log (es. Kafka/Pulsar) abilita propagazione decoupled: Ordine Creato, Pagamento Autorizzato, Spedizione Avviata. La regola d’oro: eventi descrittivi del fatto di dominio, non comandi mascherati. Le saghe coordinano processi distribuiti con compensazioni chiare: se fallisce il pagamento, l’ordine ritorna a Pending e le riserve di stock si rilasciano. Preferire coreografia per flussi semplici (riduce l’orchestrator bottleneck); adottare orchestrazione per step strettamente sequenziali o policy di compliance (audit, antiriciclaggio). Il delivery va almeno at-least-once con deduplica; gli eventi non critici possono essere best-effort per risparmiare risorse.
Scalabilità multi-paese: dati, regole e latenza dalla fonte
Espandersi in più Paesi richiede multi-tenancy, localizzazione e confini normativi. Modello a tenant logici per brand/Paese, con routing dei dati sul perimetro giusto. La residenza dei dati guida la scelta dei region: pagamenti ed analytics possono avere storage separati con cifratura KMS e chiavi per giurisdizione. Localizzazione: valute, tassazione, indirizzi, formati, calendari. Motore fiscale estendibile per VAT/GST, aggiornabile senza deploy. La latenza si riduce con edge cache per catalogo e ricerca, read replica regionali e code per burst di traffico. Feature flag per rilasci graduali, separando configurazioni per Paese da codice.
Checklist di readiness tecnica: dalla teoria al go-live
Una checklist coerente evita sorprese in produzione. Validare i domini con esempi reali, rivedere i confini dei servizi e misurare le dipendenze. Verificare che ogni API critico sia idempotente, versionato e documentato. Testare le saghe con scenari happy path e fallimenti: timeout, rollback, doppie consegne. Stress test su ordini, promozioni e stock. Valutare la multi-paese valute, tassazione, compliance KYC/AML, residenza dei dati. Controllare osservabilità, SLO e piani di capacità. Preparare runbook incidenti, DB failover e escalation. Solo quando tutti i punti sono verdi, abilitare feature flag nei mercati target.
- Domini e confini definiti con esempi e ubiquitous language
- Contratti API versionati, test di contratto e rate limit
- Eventi di dominio con schema stabile e schema registry
- Saghe con passi e compensazioni documentate
- Data residency, cifratura e segregazione dei tenant
- Observability: tracing distribuito, log con correlazione e metriche
- Performance: test di carico, resilienza, circuit breaker
- Feature flag e rollout graduale per Paese
Observability, affidabilità e governance: tenere la rotta nel tempo
Senza visibilità, anche la migliore architettura degrada. Tracing distribuito su ogni chiamata, correlation ID propagati e log strutturati consentono diagnosi rapide. Definire SLO per funzioni core (es. creazione ordine, autorizzazione pagamento) con error budget guida i rilasci. Policy di retry con jitter, circuit breaker e bulkhead proteggono dal cascading failure. La governance evita la deriva: revisione dei contratti, standard per naming degli eventi, linters su OpenAPI e policy IaC. Una platform team offre componenti condivisi (observability, CI/CD, sicurezza) lasciando ai team di dominio autonomia per innovare senza blocchi.
