Vendere su più marketplace: architettura multicanale su Azure

Vendere su un marketplace è un progetto; vendere su cinque diventa un sistema. Senza un'architettura pensata, ogni nuovo canale aggiunge codice, eccezioni e fragilità. La soluzione è un hub di integrazione multicanale con un modello canonico al centro.

Il problema della crescita lineare

Collegare ogni sistema interno a ogni marketplace genera un numero di connessioni che esplode con i canali. La risposta è introdurre un punto centrale: l'hub parla un linguaggio comune verso l'interno e tanti "dialetti" verso i marketplace, tramite connettori dedicati.

Il modello canonico

Al centro c'è una rappresentazione neutra dei concetti di business: prodotto, offerta, ordine, spedizione, movimento finanziario. ERP e marketplace si agganciano a questo modello, non l'uno all'altro. Cambiare o aggiungere un canale non tocca il nucleo.

Connettori e anti-corruption layer

Componente	Responsabilità
Connettore marketplace	Parla l'API specifica (eBay, Amazon, Shopify…)
Anti-corruption layer	Traduce tra modello canonico e modello del canale
Mapping	Attributi, categorie, regole per canale
Orchestrazione	Coordina i flussi e gli stati

L'anti-corruption layer è la chiave: impedisce che le peculiarità di un marketplace "contaminino" il modello interno, mantenendo il nucleo pulito.

I flussi principali

• Catalogo e offerte: dal modello canonico ai marketplace, per delta;
• Stock e prezzi: propagazione rapida con buffer e listini per canale;
• Ordini: dai marketplace al modello canonico e all'ERP;
• Finanze: payout e commissioni riconciliati per canale.

Architettura su Azure

Su Microsoft Azure l'hub si realizza con componenti disaccoppiati: code (Service Bus) per gli eventi, worker per ciascun connettore, gestione sicura dei segreti (Key Vault + Managed Identity), pattern di retry e rate limiting per ogni API, e osservabilità centralizzata con correlation ID per seguire un ordine attraverso tutti i passi.

Esempio di modello canonico

Il modello canonico non deve copiare eBay, Amazon o Shopify. Deve rappresentare il tuo dominio interno e lasciare ai connettori il compito di tradurre. Un prodotto pubblicabile può essere serializzato così:

{
  "sku": "ERP-12345",
  "title": { "it": "Scarpa running uomo", "en": "Men running shoe" },
  "brand": "Example",
  "identifiers": { "gtin": "8051234567890", "mpn": "RUN-12345" },
  "availability": { "warehouse": "IT-01", "quantity": 17, "safetyBuffer": 2 },
  "prices": [{ "currency": "EUR", "list": "retail", "value": 79.90 }],
  "attributes": { "color": "black", "size": "42" }
}

Il connettore eBay traduce attributes in aspetti di categoria, Amazon in product type attributes, Shopify in opzioni/variant metafield. Il core non deve conoscere questi dettagli.

Caso operativo: aggiungere il terzo canale

Quando aggiungi Shopify dopo eBay e Amazon, non riscrivi la pipeline ERP. Aggiungi una tabella di mapping per location, varianti e immagini, un worker Shopify e una regola di pubblicazione. Gli eventi canonici restano gli stessi: ProductChanged, StockChanged, PriceChanged, OrderImported. Questo è il punto in cui l'hub ripaga il costo iniziale.

Aggiungere un nuovo canale

Con questo modello, integrare un nuovo marketplace significa scrivere un connettore e definire il mapping, senza toccare il nucleo né gli altri canali. È così che l'architettura passa da "ogni canale è un nuovo progetto" a "ogni canale è una configurazione".

Errori comuni

• integrazioni punto-a-punto che crescono in modo esplosivo;
• peculiarità di un marketplace che invadono il modello interno;
• mapping e regole duplicati per ogni canale;
• nessuna osservabilità trasversale ai canali.

Conclusione

Un hub multicanale con modello canonico, connettori e anti-corruption layer trasforma la complessità in scalabilità. È l'architettura che permette di vendere su molti marketplace mantenendo il sistema comprensibile, affidabile e pronto al prossimo canale.