Branch by Abstraction: sostituire un componente dietro un contratto stabile
Branch by Abstraction introduce un'astrazione stabile davanti a vecchia e nuova implementazione, permettendo sostituzione e rollback controllati nello stesso flusso applicativo.
Che problema risolve
Alcune sostituzioni non richiedono un intero Strangler a livello di routing. Se un'applicazione usa direttamente un provider, repository o client esterno, si può prima introdurre un contratto astratto e poi cambiare l'implementazione dietro quel contratto.
Sequenza
Estrarre un'interfaccia dal comportamento realmente necessario, non da tutte le API del legacy.
Adattare l'implementazione corrente a quella interfaccia senza cambiare comportamento.
Creare la nuova implementazione in parallelo.
Aggiungere selezione per configurazione, feature flag o percentuale di traffico.
Confrontare comportamento e telemetria.
Rimuovere la vecchia implementazione e, quando non serve più, semplificare l'astrazione.
Esempi adatti
Identity Provider: Keycloak oggi, provider federato domani.
Imaging Viewer: viewer legacy oggi, DICOMweb/VueMotion tramite adapter domani.
Repository documentale o servizio di firma.
Motore di reporting o renderer PDF.
Accesso a una vecchia anagrafica sostituito progressivamente dall'EMPI.
Differenza rispetto a Strangler Fig
Strangler Fig opera tipicamente sul confine esterno di una capability e devia richieste tra sistemi. Branch by Abstraction opera dentro un'applicazione o un bounded context e sostituisce una dipendenza dietro un'interfaccia. I due pattern possono essere combinati.
Il rischio
L'astrazione può diventare il minimo comune denominatore tra vecchio e nuovo, impoverendo il dominio. Va progettata dal punto di vista del consumer moderno. Se le semantiche sono diverse, serve anche un ACL.
Perché aiuta il rollback
Poiché entrambe le implementazioni rispettano lo stesso contratto, il rollback può essere un cambio di configurazione invece di un ripristino applicativo completo. Questo è utile nelle fasi di cutover ad alto rischio.