Mönster för skyddande lager
Implementera en 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 delsystemen genom att placera ett skyddande lager mellan dem. Det här lagret översätter kommunikationen mellan de två systemen, vilket gör att det ena systemet förblir oförändrat medan det andra kan undvika att äventyra sin design och tekniska metod.
Diagrammet ovan visar ett program med två undersystem. Undersystem A anropar undersystem B via ett skyddande lager. Kommunikationen mellan delsystem A och det skyddande lagret använder alltid datamodellen och arkitekturen i delsystemet A. Anrop från det skyddande lagret till undersystem B överensstämmer med det undersystemets 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.
- Överväg om det skyddande lagret behöver hantera all kommunikation mellan olika undersystem eller bara en delmängd av funktionerna.
- Om det skyddande lagret är en del av en programmigreringsstrategi bör du överväga om det kommer att vara permanent eller kommer att dras tillbaka när alla äldre funktioner har migrerats.
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 måste 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.