Implementujte vrstvu fasády nebo adaptéru mezi různými subsystémy, které nesdílejí stejnou sémantiku. Tato vrstva překládá požadavky, které jeden subsystém provádí do druhého subsystému. Tento vzor použijte k zajištění, aby návrh aplikace nebyl omezen závislostmi na vnějších subsystémech. Tento vzor poprvé popsal Eric Evans v Domain-Driven Design.
Kontext a problém
Většina aplikací spoléhá na jiné systémy pro některá data nebo funkce. Pokud je například starší verze aplikace migrována do moderního systému, může stále potřebovat existující starší prostředky. Nové funkce musí být schopné volat starší systém. To platí zejména v případě postupné migrace, kdy se různé funkce větší aplikace v průběhu času přesunou do moderního systému.
Tyto starší systémy často trpí problémy s kvalitou, jako jsou konvolutovaná schémata dat nebo zastaralá rozhraní API. Funkce a technologie používané ve starších systémech se mohou výrazně lišit od modernějších systémů. Aby mohla nová aplikace spolupracovat se starší verzí systému, může být potřeba podporovat zastaralou infrastrukturu, protokoly, datové modely, rozhraní API nebo jiné funkce, které byste jinak nevložili do moderní aplikace.
Udržování přístupu mezi novými a staršími systémy může vynutit, aby nový systém dodržoval alespoň některá z rozhraní API starší verze systému nebo jiné sémantiky. Pokud mají tyto starší funkce problémy s kvalitou, podporují je "poškozené", což by jinak mohlo být čistě navržená moderní aplikace.
Podobné problémy můžou nastat u jakéhokoli externího systému, který váš vývojový tým neřídí, nejen starší systémy.
Řešení
Izolujte různé subsystémy tak, že mezi ně umístíte vrstvu proti poškození. Tato vrstva překládá komunikaci mezi těmito dvěma systémy, což umožňuje, aby jeden systém zůstal nezměněný, zatímco druhý může zabránit ohrožení jeho návrhu a technologického přístupu.
Výše uvedený diagram znázorňuje aplikaci se dvěma subsystémy. Subsystém A volá subsystém B prostřednictvím vrstvy proti poškození. Komunikace mezi subsystémem A a vrstvou proti poškození vždy používá datový model a architekturu subsystému A. Volání z vrstvy proti poškození do subsystému B odpovídají datovému modelu nebo metodám daného subsystému. Vrstva proti poškození obsahuje veškerou logiku potřebnou k překladu mezi těmito dvěma systémy. Vrstvu je možné implementovat jako součást v rámci aplikace nebo jako nezávislá služba.
Problémy a důležité informace
- Vrstva proti poškození může přidat latenci volání provedených mezi těmito dvěma systémy.
- Vrstva proti poškození přidává další službu, která se musí spravovat a udržovat.
- Zvažte, jak se bude škálovat vrstva proti poškození.
- Zvažte, jestli potřebujete více než jednu vrstvu proti poškození. Možná budete chtít rozložit funkce do více služeb pomocí různých technologií nebo jazyků nebo může existovat další důvody pro rozdělení vrstvy proti poškození.
- Zvažte, jak bude vrstva proti poškození spravována ve vztahu k vašim jiným aplikacím nebo službám. Jak bude integrovaná do procesů monitorování, vydávání a konfigurace?
- Ujistěte se, že jsou zachovány transakce a konzistence dat a je možné je monitorovat.
- Zvažte, jestli vrstva proti poškození potřebuje zpracovat veškerou komunikaci mezi různými subsystémy, nebo jen podmnožinou funkcí.
- Pokud je vrstva ochrany proti poškození součástí strategie migrace aplikací, zvažte, jestli bude trvalá, nebo bude vyřazena po migraci všech starších funkcí.
- Tento model je ilustrován různými subsystémy výše, ale může se vztahovat i na jiné architektury služeb, například při integraci staršího kódu do monolitické architektury.
Kdy použít tento vzor
Tento model použijte v těchto případech:
- Migrace se plánuje provést v několika fázích, ale je potřeba zachovat integraci mezi novými a staršími systémy.
- Dva nebo více subsystémů mají různé sémantiky, ale stále potřebují komunikovat.
Tento model nemusí být vhodný, pokud mezi novými a staršími systémy nejsou významné sémantické rozdíly.
Návrh úloh
Architekt by měl vyhodnotit způsob použití vzoru vrstvy proti poškození v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Například:
| Pilíř | Jak tento model podporuje cíle pilíře |
|---|---|
| efektivita provozu pomáhá poskytovat kvality úloh prostřednictvím standardizovaných procesů a soudržnosti týmu. | Tento model pomáhá zajistit, aby návrh nových komponent zůstal neovlivněný staršími implementacemi, které můžou mít různé datové modely nebo obchodní pravidla při integraci s těmito staršími systémy, a zároveň může snížit technický dluh v nových komponentách a zároveň podporovat stávající komponenty. - OE:04 Nástroje a procesy |
Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.