Mönster för skikt mot korruption

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 beroenden på externa undersystem inte begränsar ett programs design. Eric Evans beskrev först detta mönster i Domain-Driven Design: Tackling Complexity in the Heart of Software.

Kontext och problem

De flesta program förlitar sig på andra system för vissa data eller funktioner. När du till exempel migrerar ett äldre program till ett modernt system kan programmet fortsätta att använda befintliga äldre resurser. Nya funktioner måste kunna anropa det äldre systemet. Den här funktionen är särskilt viktig för gradvisa migreringar där du flyttar olika funktioner i ett större program till ett modernt system över tid.

Dessa äldre system har ofta kvalitetsproblem som invecklade datascheman eller föråldrade API:er. De funktioner och tekniker som äldre system använder kan variera mycket från modernare system. För att samverka med det äldre systemet kan det nya programmet behöva stödja inaktuell infrastruktur, protokoll, datamodeller, API:er eller andra funktioner som du annars inte skulle använda i ett modernt program.

När du behåller åtkomsten mellan nya och äldre system tvingar du det nya systemet att följa åtminstone några av det äldre systemets API:er eller andra semantik. När dessa äldre funktioner har kvalitetsproblem skadas det här stödet av vad som annars skulle kunna vara ett rent utformat modernt program.

Liknande problem kan uppstå med alla externa system som utvecklingsteamet inte styr.

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. Med den här metoden kan du hålla det ena systemet oförändrat utan att äventyra den andras design och tekniska tillvägagångssätt.

Ladda ned en Visio-fil av den här arkitekturen.

Diagrammet visar ett program som har 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. Antikorruptionsskiktet innehåller all logik som krävs för att översätta mellan de två systemen. Du kan implementera lagret som en komponent i programmet eller som en oberoende tjänst.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera det här mönstret:

• Antikorruptionsskiktet lägger till svarstid för anrop mellan de två systemen.

• Lagret mot korruption lägger till en extra tjänst som du måste hantera och underhålla.

• Fundera på hur du planerar att skala skiktet mot korruption.

• Överväg om du behöver mer än ett lager för korruptionsbekämpning. Du kanske till exempel vill dela upp funktioner i flera tjänster som använder olika tekniker eller språk.

• Överväg hur du planerar att hantera skiktet mot korruption i förhållande till dina andra program eller tjänster och hur du integrerar det i dina övervaknings-, lanserings- och konfigurationsprocesser.

• Se till att du underhåller och övervakar transaktions- och datakonsekvens.

• 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 programmigreringsstrategi bör du överväga om det är permanent eller om du planerar att dra tillbaka det när du har migrerat alla äldre funktioner.

• I föregående diagram används distinkta undersystem för att illustrera det här mönstret, men du kan också använda det på andra tjänstarkitekturer, till exempel äldre kodintegrering i en monolitisk arkitektur.

• Eftersom antikorruptionsskiktet förmedlar system som kan ha olika förtroendenivåer bör du överväga att framtvinga validering och sanering av indata vid den här gränsen.

• Planera för observerbarhet, inklusive korrelations-ID:er och strukturerad loggning, för att diagnostisera översättningsfel.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

• Du planerar att en migrering ska ske i flera steg, men du måste upprätthålla integreringen mellan nya och äldre system.

• Två eller flera undersystem har olika semantik, men de måste kommunicera.

Det här mönstret kanske inte är lämpligt när:

• De nya och äldre systemen har inga betydande semantiska skillnader. I det här scenariot är det viktigt att fokusera skiktet mot korruption på översättningslogik. Undvik att placera affärsregler eller orkestrering i lagret.

Design av arbetsbelastning

Utvärdera hur man använder mönstret Anticorruption Layer i utformningen av en arbetsbelastning för att uppfylla de mål och principer som behandlas i pelarna i Azure Well-Architected Framework. Följande tabell innehåller vägledning om hur det här mönstret stöder målen för varje pelare.

Om detta mönster inför kompromisser inom en pelare bör du överväga dem mot målen för de andra pelarna.

Example

Det här mönstret är konceptuellt och kommer från den domändrivna designmetoden för programvaruutveckling. Azure tjänster som Azure API Management eller Azure Functions kan hjälpa till med protokollhantering och översättning, men huvudsyftet med ett lager mot korruption är att skydda domänmodellen, inte att föreskriva något specifikt produktval.

I följande exempel hanterar API Management de externa exponerings- och protokollproblemen. Azure Functions implementerar skiktet mot korruption genom domänmappning mellan det nya systemet och det äldre systemet. Azure Monitor och Application Insights ger den observerbarhet som du behöver för att spåra framgång och svarstid för översättningen mellan de två undersystemen.

Utöver den här synkrona modellen för begärandesvar kan antikorruptionsskiktet också använda en asynkron, händelsedriven metod. Genom att använda Azure Service Bus, Azure Event Grid eller Azure Event Hubs frikopplar lagret den moderna domänen från det äldre systemets dataflödesbegränsningar för att tillåta meddelandebaserad översättning för högt dataflöde eller mycket frikopplade arbetsbelastningar.

Nästa steg

• Utforska mönster för molndesign som hjälper dig att hantera distribuerade transaktioner och upprätthålla datakonsekvens, till exempel mönster för kompenserande transaktion och Saga-distribuerade transaktioner.

• Eftersom antikorrumtionslagret kan bli en enda felpunkt bör du planera för resiliens med hjälp av återförsöksmönstret, kretsbrytarmönstret, Bulkhead-mönstret och mönstret för övervakning av hälsoändpunkter.

Relaterade resurser

• Strangler Fig-mönster
• Mönster för meddelandebrygga