Come si esegue la migrazione da un monolite a microservizi utilizzando il pattern strangler-fig?

Question

Accepted Answer

Il **pattern strangler-fig** esegue la migrazione in modo incrementale: si avvolge il monolite con un livello di routing, si estrae una capacità alla volta in un servizio, e si reindirizza il traffico verso di esso — finché il monolite non viene "strangolato". **Non esiste una riscrittura big-bang**.

## Come funziona

```text
Step 1: route all traffic through a facade/proxy to the monolith
Step 2: extract ONE capability → new service
Step 3: route just that path to the new service
Step 4: repeat; delete that code from the monolith

Client ─▶ [ Proxy ] ─┬─▶ /orders  ─▶ NEW Orders service
                       └─▶ everything else ─▶ Monolith
```

## Scelta di cosa estrarre per primo

```text
✓ A bounded context with clear boundaries
✓ Something that needs independent scaling or deploys
✓ A part with few inbound dependencies (low risk)
✗ Don't start with the tangled core
```

## Gestione dei dati condivisi

La parte difficile è il database. Estrarre le tabelle del servizio, quindi interrompere l'accoppiamento del DB condiviso utilizzando eventi o un livello anti-corruption, spesso tramite la tecnica **branch-by-abstraction** mentre entrambi sono in esecuzione.

## Compromessi

```text
✓ Low risk — small, reversible steps, always shippable
✓ Value early, learn the seams as you go
✗ Slow; you run a hybrid system for a long time
✗ Temporary duplication and routing complexity
```

## Perché è importante
"
 Le riscritture big-bang sono notoriamente famose per fallire — congelano il lavoro sulle funzionalità per mesi e distribuiscono un cutover rischioso all'interno di una sola volta.

Il pattern strangler-fig mantiene il sistema live e rilasciabile per tutto il tempo, consente di fermarsi o riprioritizzare in qualsiasi momento, e ti forza a scoprire i confini reali dei servizi dal sistema in esecuzione piuttosto che indovinarli in anticipo.