BFF e API Gateway: front door, composizione e Strangler routing

API Gateway

L'API Gateway è il punto di ingresso tecnico per routing, TLS, policy, rate limiting, autenticazione e osservabilità. Durante uno Strangler può decidere se una capability viene servita dal legacy o dal nuovo servizio senza modificare i client.

Backend for Frontend

Il BFF è più vicino all'esperienza utente: compone risposte per un frontend specifico, riduce round trip, normalizza errori e propaga il contesto di sicurezza. In un Application Shell con microfrontend può offrire endpoint orientati alle schermate pur lasciando i bounded context indipendenti.

Cosa NON deve fare

• Decidere regole di ricovero, dimissione o trasferimento.

• Calcolare lo stato autorevole di un ordine.

• Accedere direttamente ai database di più bounded context.

• Diventare il posto dove si inserisce ogni eccezione del legacy.

• Conservare copie autorevoli dei dati solo per comodità della UI.

Gateway vs Facade

Il Gateway è soprattutto un boundary infrastrutturale e di routing. La Facade semplifica un sottosistema applicativo. Possono coesistere: il Gateway instrada verso una LegacyFacade durante la migrazione e verso il nuovo bounded context dopo il cutover.

Security

Il gateway può validare token e applicare policy grossolane, ma l'autorizzazione di dominio deve essere verificata anche dal servizio proprietario. Non bisogna affidarsi all'idea che «se è passato dal gateway allora è autorizzato».

Osservabilità

Il punto di ingresso deve generare o propagare correlationId/traceId e conservarli lungo BFF, servizi, adapter e messaggi. Questo rende possibile seguire una singola operazione anche quando attraversa il confine tra nuovo e legacy.

Quando separare Gateway e BFF

Quando esistono più consumer, esigenze di sicurezza/infrastruttura comuni e frontend con composizioni diverse, è utile distinguere i due ruoli. In sistemi più piccoli possono essere implementati nello stesso componente, purché le responsabilità restino concettualmente separate.