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 het ontwerp van een toepassing niet wordt beperkt door afhankelijkheden van externe subsystemen. Dit patroon werd voor het eerst beschreven door Eric Evans in Domain-Driven Design.
Context en probleem
De meeste toepassingen zijn voor sommige gegevens of functionaliteiten afhankelijk van andere systemen. Wanneer een oudere toepassing bijvoorbeeld wordt gemigreerd naar een modern systeem, heeft het mogelijk nog steeds bestaande oudere resources nodig. Nieuwe functies moeten het oude systeem kunnen aanroepen. Dit is vooral waar voor geleidelijke migratie, waarbij verschillende functies van een grotere toepassing in de loop van de tijd worden verplaatst naar een modern systeem.
Vaak lijden deze oudere systemen onder kwaliteitsproblemen zoals ingewikkelde gegevensschema's of verouderde API's. De functies en technologieën die worden gebruikt in oudere systemen kunnen sterk verschillen van moderne systemen. Als u wilt samenwerken met het oudere 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.
Het beheren van toegang tussen de nieuwe en bestaande systemen kan het nieuwe systeem dwingen om in overeenstemming te zijn met ten minste een deel van de API's of andere semantiek van het oude systeem. Wanneer deze verouderde functies kwaliteitsproblemen hebben, 'corrumpeert' het ondersteunen hiervan iets, wat anders een goed ontworpen moderne toepassing is.
Vergelijkbare problemen kunnen zich voordoen met elk extern systeem dat uw ontwikkelteam niet controleert, niet alleen verouderde systemen.
Oplossing
Isoleer de verschillende subsystemen door er een anti-corruptielaag tussen te plaatsen. Deze laag vertaalt de communicatie tussen de twee systemen, waardoor het ene systeem ongewijzigd blijft, terwijl de andere de ontwerp- en technologische benadering in gevaar kan brengen.
In het bovenstaande 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 anti-corruptielaag bevat alle logica die nodig is voor de omzetting tussen de twee systemen. De laag kan worden geïmplementeerd als een onderdeel in de toepassing of als een onafhankelijke service.
Problemen en overwegingen
- De anti-corruptielaag voegt mogelijk latentie toe aan aanroepen tussen de twee systemen.
- De anti-corruptielaag voegt een extra service toe die moet worden beheerd en onderhouden.
- Overweeg hoe uw anti-corruptielaag wordt geschaald.
- Overweeg of u meer dan één anti-corruptielaag nodig heeft. Het is misschien raadzaam om functionaliteit in meerdere services op te delen met behulp van verschillende technologieën of talen, of mogelijk zijn er andere redenen voor het partitioneren van de anti-corruptielaag.
- Houd rekening met hoe de anti-corruptielaag wordt beheerd met betrekking tot uw andere toepassingen of services. Hoe wordt de laag geïntegreerd in uw bewakings-, publicatie- en configuratieprocessen?
- Zorg ervoor dat transactie- en gegevensconsistentie worden bewaard en kunnen worden gecontroleerd.
- Overweeg of de anti-corruptielaag alle communicatie tussen verschillende subsystemen moet verwerken, of alleen een subset van functies.
- Als de anti-corruptielaag deel uitmaakt van een strategie voor toepassingsmigratie, moet u overwegen of deze permanent is of buiten gebruik wordt gesteld nadat alle verouderde functionaliteit is gemigreerd.
- Dit patroon wordt geïllustreerd met verschillende subsystemen hierboven, maar kan ook worden toegepast op andere servicearchitecturen, zoals bij het integreren van verouderde code in een monolithische architectuur.
Wanneer dit patroon gebruiken
Gebruik dit patroon wanneer:
- Een migratie is gepland om in meerdere fasen te gebeuren, maar de integratie tussen nieuwe en bestaande systemen moet worden onderhouden.
- Twee of meer subsystemen hebben verschillende semantiek, maar moeten nog steeds communiceren.
Dit patroon is mogelijk niet geschikt als er geen belangrijke semantische verschillen tussen nieuwe en bestaande systemen zijn.
Workloadontwerp
Een architect moet evalueren hoe het anticorruptielaagpatroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:
| 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 en dat het technische schulden in nieuwe onderdelen kan verminderen terwijl bestaande onderdelen nog steeds worden ondersteund. - OE:04 Hulpprogramma's en processen |
Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.