Kuinka siirrät monoliitin mikroselvityksiin käyttämällä strangler-fig-mallia?

Question

Accepted Answer

**Strangler-fig-malli** siirtää asteittain: käärit monoliitin reititykerroksella, poimit yhden kyvyn kerrallaan palveluun ja ohjaat liikenteen siihen — kunnes monoliitti on "kuristettu". Ei ole **suurta uudelleenkirjoitusta**.

## Kuinka se toimii

```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
```

## Valinta siitä, mitä poimitaan ensin

```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
```

## Jaettujen tietojen hallinta

Vaikea osa on tietokanta. Poimi palvelun taulukot, katkaise sitten jaettu DB-kytkentä käyttämällä tapahtumia tai anti-corruption-kerrosta, usein **branch-by-abstraction**-tekniikan kautta molempien ollessa käynnissä.

## Kompromissit

```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
```

## Miksi se on tärkeää

Suuret uudelleenkirjoitukset epäonnistuvat kuuluisasti — ne jäädyttävät ominaisuustyön kuukausiksi ja lähettävät riskialtiin kerralla-tehtävä-siirron.

Strangler-fig-malli pitää järjestelmän eläväksi ja vapautettavaksi koko ajan, antaa sinun pysäyttää tai asettaa prioriteetit uudelleen missä tahansa vaiheessa ja pakottaa sinua löytämään todelliset palvelun rajat käynnissä olevasta järjestelmästä etukäteen arvaamisen sijaan.