Adapter e Facade: compatibilità e semplificazione non sono la stessa cosa

Adapter: cambiare la forma, non l'intento

L'Adapter Pattern converte l'interfaccia di un componente in quella attesa dal chiamante. È particolarmente utile quando il dominio deve restare stabile ma il provider può cambiare. Una ImagingViewerPort può avere VueMotionAdapter, DICOMwebAdapter e LegacyViewerAdapter.

Facade: ridurre la superficie

La Facade espone un'interfaccia più semplice davanti a un sottosistema complesso. Un legacy può richiedere cinque chiamate, tre codici tecnici e una sequenza rigida; una LegacyClinicalFacade può offrire un'unica operazione getClinicalSummary. La complessità resta dietro la facciata invece di propagarsi ai nuovi consumer.

Differenza essenziale

• Adapter risolve incompatibilità di interfaccia o protocollo.

• Facade riduce la complessità percepita e la superficie pubblica.

• Anti-Corruption Layer risolve incompatibilità semantica tra modelli di dominio.

• Una soluzione reale può avere Facade → ACL → Adapter, ciascuno con una responsabilità diversa.

Esempio di composizione

Il nuovo Clinical Record invoca LegacyClinicalPort. Una Facade raggruppa le operazioni necessarie; un ACL traduce episodi, stati e codici; un FirebirdAdapter o RestAdapter esegue concretamente la comunicazione. Il chiamante vede un contratto di dominio piccolo e stabile.

Il rischio della Facade eterna

Una Facade può diventare un comodo contenitore in cui accumulare nuove regole. Se ospita business logic del nuovo dominio, crea un secondo legacy. Durante una migrazione deve essere trattata come boundary temporaneo o come API di composizione con responsabilità strettamente definite.

Come scegliere

• Protocollo diverso ma stessa semantica → Adapter.

• Troppe API legacy da semplificare → Facade.

• Concetti legacy diversi dal nuovo dominio → ACL.

• Sostituzione incrementale dell'intero sottosistema → aggiungere Strangler Fig.