Implementera ett fasad- eller adapterlager mellan olika undersystem som inte delar samma semantik. Det här lagret översätter begäranden som ett undersystem gör till det andra undersystemet. Använd det här mönstret för att säkerställa att ett programs design inte begränsas av beroenden på externa undersystem. Det här mönstret beskrevs först av Eric Evans i Domain-Driven Design.
Kontext och problem
De flesta program som förlitar sig på andra system för vissa data eller funktioner. När ett äldre program migreras till ett modern system kanske det fortfarande behöver befintliga, äldre resurser. Nya funktioner måste kunna anropa det äldre systemet. Det gäller särskilt för stegvis migrering där olika funktioner i ett större program under en längre flyttas till ett modernt system.
De äldre systemen lider ofta av kvalitetsproblem, till exempel komplexa datascheman eller föråldrade API:er. De funktioner och tekniker som används i äldre system kan skilja sig stort från mer moderna system. Om du vill använda de äldre systemen kanske det nya programmet måste ha stöd för inaktuella infrastrukturer, protokoll, datamodeller, API:er eller andra funktioner som du annars inte skulle ha i ett modernt program.
Att upprätthålla åtkomsten mellan nya och äldre system kan tvinga det nya systemet att följa åtminstone vissa av det äldre systemets API:er eller annan semantik. När sådana här äldre funktioner har kvalitetsproblem innebär det att du ”skadar” ett modernt program i och med att du bygger in stödet för de äldre funktionerna.
Liknande problem kan uppstå med alla externa system som utvecklingsteamet inte styr, inte bara äldre system.
Lösning
Isolera de olika undersystemen genom att placera ett lager för korruptionsbekämpning mellan dem. Det här lagret översätter kommunikationen mellan de två systemen, vilket gör att det ena systemet kan förbli oförändrat medan det andra kan undvika att äventyra dess design och tekniska tillvägagångssätt.
Diagrammet ovan visar ett program med två undersystem. Undersystem A anropar undersystem B via ett lager för korruptionsbekämpning. Kommunikationen mellan undersystem A och antikorruptionslagret använder alltid datamodellen och arkitekturen i undersystem A. Anrop från antikorruptionslagret till delsystem B överensstämmer med det delsystemets datamodell eller -metoder. Det skyddande lagret innehåller all den logik som behövs för att översätta mellan de två systemen. Lagret kan implementeras som en komponent i programmet eller som en fristående tjänst.
Problem och överväganden
- Det skyddande lagret kan förlänga svarstiden för anrop mellan de två systemen.
- Det skyddande lagret lägger till ytterligare en tjänst som måste hanteras och underhållas.
- Överväg hur det skyddande lagret kan skalanpassas.
- Överväg om du behöver mer än ett lager skyddande lager. Du kanske vill dela upp funktionerna på flera tjänster med olika tekniker eller språk, eller det kan finnas andra orsaker att partitionera det skyddande lagret.
- Överväg hur det skyddande lagret ska hanteras i förhållande till andra program eller tjänster. Hur ska det integreras i dina processer för övervakning, lansering och konfiguration?
- Se till att transaktions- och datakonsekvens upprätthålls och kan övervakas.
- Fundera på om antikorruptionsskiktet behöver hantera all kommunikation mellan olika undersystem eller bara en delmängd av funktionerna.
- Om antikorruptionsskiktet är en del av en strategi för programmigrering bör du överväga om det kommer att vara permanent eller dras tillbaka när alla äldre funktioner har migrerats.
- Det här mönstret illustreras med distinkta undersystem ovan, men kan även gälla för andra tjänstarkitekturer, till exempel när äldre kod integreras i en monolitisk arkitektur.
När du ska använda det här mönstret
Använd det här mönstret i sådana här scenarier:
- En migrering planeras i flera faser, men integreringen mellan nya och äldre system måste upprätthållas.
- Två eller flera undersystem har olika semantik, men behöver fortfarande kommunicera.
Det här mönstret kanske inte är lämpligt om det inte finns några betydande semantiska skillnader mellan nya och äldre system.
Design av arbetsbelastning
En arkitekt bör utvärdera hur mönstret för lager mot korruption kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:
| Grundpelare | Så här stöder det här mönstret pelarmål |
|---|---|
| Operational Excellence hjälper till att leverera arbetsbelastningskvalitet genom standardiserade processer och teamsammanhållning. | Det här mönstret hjälper till att säkerställa att den nya komponentdesignen förblir opåverkade av äldre implementeringar som kan ha olika datamodeller eller affärsregler när du integrerar med dessa äldre system och det kan minska den tekniska skulden i nya komponenter samtidigt som befintliga komponenter stöds. - OE:04 Verktyg och processer |
Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.