Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Implementeer een gevel- of adapterlaag tussen verschillende subsystemen die niet dezelfde semantiek delen. Deze laag vertaalt aanvragen die door het ene subsysteem naar het andere subsysteem worden verzonden. Gebruik dit patroon om ervoor te zorgen dat afhankelijkheden van externe subsystemen het ontwerp van een toepassing niet beperken. Eric Evans beschreef dit patroon eerst in Domain-Driven Design: De complexiteit aanpakken in het hart van software.
Context en probleem
De meeste toepassingen zijn afhankelijk van andere systemen voor bepaalde gegevens of functionaliteit. Wanneer u bijvoorbeeld een verouderde toepassing migreert naar een modern systeem, kan de toepassing bestaande verouderde resources blijven gebruiken. Nieuwe functies moeten het verouderde systeem kunnen aanroepen. Deze mogelijkheid is vooral belangrijk voor geleidelijke migraties waarbij u verschillende functies van een grotere toepassing in de loop van de tijd naar een modern systeem verplaatst.
Deze verouderde systemen hebben vaak kwaliteitsproblemen, zoals ingewikkelde gegevensschema's of verouderde API's. De functies en technologieën die oudere systemen gebruiken, kunnen sterk verschillen van modernere systemen. Als u wilt samenwerken met het verouderde systeem, moet de nieuwe toepassing mogelijk verouderde infrastructuur, protocollen, gegevensmodellen, API's of andere functies ondersteunen die u anders niet in een moderne toepassing zou plaatsen.
Wanneer u de toegang tussen nieuwe en legacysystemen in stand houdt, dwingt u het nieuwe systeem zich te houden aan ten minste enkele van de API's of andere semantische conventies van het legacysysteem. Wanneer deze verouderde functies kwaliteitsproblemen vertonen, ondermijnt die ondersteuning een verder strak ontworpen moderne applicatie.
Vergelijkbare problemen kunnen zich voordoen met elk extern systeem dat uw ontwikkelteam niet controleert.
Solution
Isoleer de verschillende subsystemen door er een anti-corruptielaag tussen te plaatsen. Deze laag vertaalt de communicatie tussen de twee systemen. Door deze benadering te gebruiken, kunt u één systeem ongewijzigd houden zonder afbreuk te doen aan het ontwerp en de technologische benadering van de andere.
Een Visio-bestand van deze architectuur downloaden.
In het diagram ziet u een toepassing met twee subsystemen. Subsysteem A roept subsysteem B aan via een anti-corruptielaag. Communicatie tussen subsysteem A en de anticorruptielaag maakt altijd gebruik van het gegevensmodel en de architectuur van subsysteem A. Aanroepen van de anti-corruptielaag naar subsysteem B voldoen aan het gegevensmodel of de methoden van dat subsysteem. De anticorruptielaag bevat alle logica die nodig is om tussen de twee systemen te vertalen. U kunt de laag implementeren als onderdeel binnen de toepassing of als een onafhankelijke service.
Problemen en overwegingen
Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:
De anti-corruptielaag voegt latentie toe aan aanroepen tussen de twee systemen.
De anti-corruptielaag voegt een extra service toe die u moet beheren en onderhouden.
Overweeg hoe u de anti-corruptielaag wilt schalen.
Overweeg of u meer dan één anti-corruptielaag nodig hebt. U kunt bijvoorbeeld functionaliteit opsnetsen in meerdere services die gebruikmaken van verschillende technologieën of talen.
Overweeg hoe u van plan bent de anti-corruptielaag te beheren in relatie tot uw andere toepassingen of services en hoe u deze integreert in uw bewakings-, release- en configuratieprocessen.
Zorg ervoor dat u transactie- en gegevensconsistentie onderhoudt en bewaakt.
Overweeg of de anti-corruptielaag alle communicatie tussen verschillende subsystemen moet verwerken, of alleen een subset van functies.
Als de anticorruptielaag deel uitmaakt van een strategie voor toepassingsmigratie, kunt u overwegen of deze permanent is of of u van plan bent deze buiten gebruik te stellen nadat u alle verouderde functionaliteit hebt gemigreerd.
In het vorige diagram worden verschillende subsystemen gebruikt om dit patroon te illustreren, maar u kunt het ook toepassen op andere servicearchitecturen, zoals integratie van verouderde code in een monolithische architectuur.
Omdat de anti-corruptielaag systemen bemiddelt die mogelijk verschillende vertrouwensniveaus hebben, kunt u overwegen om invoervalidatie en opschoning op deze grens af te dwingen.
Plan waarneembaarheid, inclusief correlatie-id's en gestructureerde logboekregistratie, om vertaalfouten vast te stellen.
Wanneer gebruikt u dit patroon?
Gebruik dit patroon wanneer:
U plant een migratie in meerdere fasen, maar u moet de integratie tussen nieuwe en verouderde systemen onderhouden.
Twee of meer subsystemen hebben verschillende semantiek, maar ze moeten communiceren.
Dit patroon is mogelijk niet geschikt wanneer:
- De nieuwe en verouderde systemen hebben geen significante semantische verschillen. In dit scenario is het belangrijk om de anti-corruptielaag te richten op vertaallogica. Vermijd het plaatsen van bedrijfsregels of indeling in de laag.
Werklastontwerp
Beoordeel hoe u het anti-corruptielaagpatroon gebruikt in het ontwerp van een workload om invulling te geven aan de doelstellingen en principes die aan bod komen in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.
| Pijler | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
|---|---|
| Operational Excellence helpt bij het leveren van workloadkwaliteit via gestandaardiseerde processen en teamcohesie. | Dit patroon helpt ervoor te zorgen dat het ontwerp van nieuwe onderdelen niet wordt beïnvloed door verouderde implementaties die mogelijk verschillende gegevensmodellen of bedrijfsregels hebben wanneer u integreert met deze verouderde systemen. Het kan technische schulden in nieuwe onderdelen verminderen terwijl bestaande onderdelen nog steeds worden ondersteund. - OE:04 Tools en processen - OE:07 Bewakingssysteem |
Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.
Example
Dit patroon is conceptueel en komt voort uit de domeingestuurde ontwerpsoftwareontwikkelingsbenadering. Azure services zoals Azure API Management of Azure Functions kunnen helpen bij het verwerken en vertalen van protocollen, maar het belangrijkste doel van een anticorruptielaag is het domeinmodel te beschermen, geen specifieke productkeuze voor te schrijven.
In het volgende voorbeeld verwerkt API Management de problemen met externe blootstelling en protocollen. Azure Functions implementeert de anti-corruptielaag via domeintoewijzing tussen het nieuwe systeem en het verouderde systeem. Azure Monitor en Application Insights bieden de waarneembaarheid die u nodig hebt om het succes en de latentie van de vertaling tussen de twee subsystemen bij te houden.
Naast dit synchrone aanvraagresponsmodel kan de anti-corruptielaag ook een asynchrone, gebeurtenisgestuurde benadering gebruiken. Door gebruik te maken van Azure Service Bus, Azure Event Grid of Azure Event Hubs, koppelt de laag het moderne domein los van de doorvoerbeperkingen van het verouderde systeem om op berichten gebaseerde vertaling toe te staan voor werkbelastingen met hoge doorvoer of zeer ontkoppelde workloads.
Volgende stappen
Verken cloudontwerppatronen die helpen bij het beheren van gedistribueerde transacties en het onderhouden van gegevensconsistentie, zoals het patroon Compenserende transactie en het patroon gedistribueerde Saga-transacties.
Omdat de anti-corruptielaag een één storingspunt kan worden, zorgt u voor veerkracht met behulp van het patroon voor opnieuw proberen, stroomonderbrekerpatroon, bulkhead-patroon en patroon voor statusendpointbewaking.