Legacy stap voor stap vervangen door een ERP, zonder big bang

Het strangler fig-patroon wordt meestal uitgelegd met een legacy-systeem dat stap voor stap vervangen wordt door een nieuw, zelfgebouwd systeem. Je bepaalt zelf hoe het nieuwe model eruitziet, en de oude code sterft langzaam af.

Steeds vaker is het doel geen eigen systeem, maar een standaardpakket: een ERP of een andere COTS-oplossing. Het patroon werkt dan nog steeds. Maar een paar dingen veranderen fundamenteel, omdat het doelmodel niet van jou is.

Het klassieke patroon in het kort

De naam komt van een vijgenboom die rond een gastboom groeit, tot die gastboom verdwijnt en alleen de vijg overblijft. Toegepast op software:

Plaats een grens tussen het oude systeem en zijn gebruikers, bijvoorbeeld een routeringslaag of een event-topic.
Bouw één stuk functionaliteit opnieuw en leid het verkeer daarvoor om.
Herhaal per stuk, tot het oude systeem niets meer doet en uitgezet kan worden.

De kracht zit in het kleine risico per stap. Er is geen big bang, en op elk moment werkt het geheel.

Wat anders is bij een standaardpakket: de ACL wordt structureel

Bij een eigen doelsysteem ontwerp je het nieuwe model rond je domein. Een anti-corruption layer (ACL) is dan vaak tijdelijk: ze vertaalt tussen oud en nieuw, en verdwijnt samen met het oude systeem.

Bij een pakket kun je het doelmodel niet naar je domein plooien. Het pakket heeft zijn eigen begrippen, granulariteit en levenscyclus. De ACL beschermt dan niet alleen tijdens de migratie, maar ook daarna: ze houdt de rest van het landschap los van het datamodel van het pakket.

	Eigen doelsysteem	Standaardpakket
Doelmodel	Ontworpen rond het domein	Opgelegd door het pakket
Rol van de ACL	Tijdelijke vertaling	Blijvende bescherming
Na de migratie	ACL kan weg	ACL blijft, als grens van het domein

Dat verandert hoe je de ACL behandelt. Het is geen wegwerpcode, maar een volwaardige component met eigenaar, tests en een levenscyclus.

Contracten als vangnet

De grens waarachter je vervangt, moet stabiel zijn. Bij event-driven integratie is dat het contract: het topic en de AsyncAPI-beschrijving van wat erover gaat. Zolang dat contract gerespecteerd wordt, weten consumers niet aan welke kant van de migratie ze praten.

Beide kanten van de migratie produceren tegen hetzelfde contract. Omschakelen betekent de producer wisselen, niet de consumers aanpassen.

Het bestaande systeem en het pakket (achter zijn ACL) produceren tegen hetzelfde contract. Een stuk omschakelen betekent: de producer wisselen, niet de consumers aanpassen.

Dat maakt contracten meer dan een testpraktijk. Een expliciet, verifieerbaar contract is de voorwaarde om veilig per grens te kunnen vervangen. AsyncAPI helpt daarbij nog op een andere manier: het beschrijft het contract los van de broker, zodat ook een wissel van eventplatform de afspraak niet breekt.

Gedrag bewaken tijdens de migratie

Een contract bewaakt de vorm van wat over de grens gaat. Of het nieuwe systeem zich ook hetzelfde gedraagt, vraagt extra technieken:

Approval tests. Leg de input en output van het oude systeem vast en toets het nieuwe pad daartegen. Elk verschil wordt zichtbaar en moet bewust goedgekeurd worden.
Parallel runs. Laat oud en nieuw een tijd naast elkaar draaien op dezelfde input, met alleen het oude systeem als bron van waarheid. Vergelijk de resultaten voor je omschakelt.
Gedragsscenario's. Given/When/Then-scenario's beschrijven het gedrag over de grens, los van de technologie erachter. Ze overleven de migratie, terwijl de implementatie erachter wisselt.

Bij een pakket zijn verschillen soms bedoeld: het pakket werkt nu eenmaal anders. Het doel is dan niet identiek gedrag, maar bewust gekozen verschillen in plaats van verrassingen.

Valkuilen

Halverwege blijven hangen. De laatste stukken zijn vaak de moeilijkste en leveren het minst zichtbare waarde op. Zonder expliciet eindpunt draai je jaren met twee systemen. Plan het uitzetten van het oude systeem als een mijlpaal, niet als een gevolg.
De ACL als vergaarbak. Omdat ze tussen alles in zit, is de verleiding groot om er business-regels in te stoppen. Houd de ACL bij vertalen. Een regel die over het domein gaat, hoort in het domein.
Onduidelijk eigenaarschap van data. Tijdens de overgang bestaan sommige gegevens in beide systemen. Leg per entiteit vast welk systeem de bron van waarheid is, en wanneer dat wisselt. Vermijd dual writes.
De grens op de verkeerde plek. Snijd per business-capability of flow, niet per technische tabel. Een stuk dat niet zelfstandig kan omschakelen, is geen goed stuk.

Afsluiting

Strangler fig richting een standaardpakket is hetzelfde patroon met een andere eindtoestand. De ACL verdwijnt niet, ze wordt de blijvende grens van je domein. En de contracten die je vandaag vastlegt, maken de migratie van morgen veilig.

Wie nu al expliciete contracten tussen domeinen invoert, bereidt een migratie voor nog voor die gepland is. Een goed afgebakende grens is een grens die je later kunt verleggen.