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. Jako první tento model popsal Eric Evans v knize Domain-Driven Design.
Kontext a problém
Většina aplikací spoléhá v souvislosti s daty nebo funkcemi na jiné systémy. Pokud je třeba starší verze aplikace migrována do moderního systému, může dále potřebovat stávající prostředky starší verze. Nové funkce musí být schopny volat starší verzi systému. Toto platí zejména pro postupné migrace, u kterých se různé funkce větších aplikací postupně přesunují do moderního systému.
Tyto starší verze systémů mají často problémy s kvalitou, například se složitými schématy dat a zastaralými rozhraními API. Funkce a technologie použité ve starších verzích systémů se mohou od moderních systémů velmi lišit. Aby mohla nová aplikace spolupracovat se starší verzí systému, může být nutné, aby podporovala zastaralou infrastrukturu, protokoly, datové modely, rozhraní API nebo jiné funkce, které byste jinak u moderní aplikace nepoužili.
Zachování přístupu mezi novou a starší verzí systému může nutit nový systém přizpůsobit se alespoň některým rozhraním API starší verze systému nebo jiné sémantice. Pokud mají tyto starší funkce problémy s kvalitou, může pak jejich podpora „zničit“ jinak zcela správně navrženou moderní aplikaci.
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 odolná proti poškození obsahuje veškerou logiku potřebnou pro překlad mezi těmito dvěma systémy. Vrstvu můžete implementovat jako komponentu v rámci aplikace nebo jako nezávislou službu.
Problémy a důležité informace
- Vrstva odolná proti poškození může přidat latenci volání prováděných mezi těmito dvěma systémy.
- Vrstva odolná proti poškození přidává další službu, kterou je nutné spravovat a udržovat.
- Zvažte, jak chcete vrstvu odolnou proti poškození škálovat.
- Zamyslete se, jestli budete potřebovat více vrstev odolných proti poškození. Funkce můžete chtít rozložit do více služeb používajících různé technologie nebo jazyky. K rozdělení vrstvy odolné proti poškození můžete mít i jiné důvody.
- Zvažte, jak budete vrstvu odolnou proti poškození spravovat vzhledem k ostatním aplikacím nebo službám. Jak se bude integrovat do procesů monitorování, vydávání a konfigurace?
- Zajistěte, aby byla udržována konzistence transakcí a dat a aby bylo možné ji 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 se má tento model použít
Tento model použijte v těchto případech:
- Máte naplánovanou migraci, ke které má dojít v několika fázích, ale potřebujete zachovat integraci mezi novým a starším systémem.
- 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ým a starším systémem neexistují žádné závažnější sémantické rozdíly.
Návrh úloh
Architekt by měl vyhodnotit, jak se dá model vrstvy proti poškození použít v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:
| Pilíř | Jak tento model podporuje cíle pilíře |
|---|---|
| Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti. | 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.