Wzorzec warstwy przeciwdegradcyjnej
Zaimplementuj warstwę fasady lub karty między różnymi podsystemami, które nie współużytkują tej samej semantyki. Ta warstwa tłumaczy żądania, które jeden podsystem wykonuje do drugiego podsystemu. Użyj tego wzorca, aby upewnić się, że projekt aplikacji nie jest ograniczony przez zależności od podsystemów zewnętrznych. Ten wzorzec został po raz pierwszy opisany przez Erica Evansa w Domain-Driven Design.
Kontekst i problem
Większość aplikacji opiera się na innych systemach dla niektórych danych lub funkcji. Na przykład gdy starsza aplikacja jest migrowana do nowoczesnego systemu, może nadal potrzebować istniejących starszych zasobów. Nowe funkcje muszą mieć możliwość wywoływania starszego systemu. Dotyczy to szczególnie stopniowego migracji, w przypadku których różne funkcje większej aplikacji są przenoszone do nowoczesnego systemu w czasie.
Często starsze systemy mają problemy z jakością, takie jak zawiłe schematy danych lub przestarzałe interfejsy API. Funkcje i technologie używane w starszych systemach mogą się znacznie różnić od bardziej nowoczesnych systemów. Aby współdziałać ze starszym systemem, nowa aplikacja może wymagać obsługi nieaktualnej infrastruktury, protokołów, modeli danych, interfejsów API lub innych funkcji, które nie byłyby w inny sposób wprowadzane do nowoczesnej aplikacji.
Utrzymywanie dostępu między nowymi i starszymi systemami może zmusić nowy system do przestrzegania co najmniej niektórych interfejsów API starszego systemu lub innych semantyki. Jeśli te starsze funkcje mają problemy z jakością, obsługa ich "uszkodzeń" może w przeciwnym razie być nowo zaprojektowaną nowoczesną aplikacją.
Podobne problemy mogą wystąpić w przypadku dowolnego systemu zewnętrznego, który zespół deweloperów nie kontroluje, a nie tylko starszych systemów.
Rozwiązanie
Izoluj różne podsystemy, umieszczając między nimi warstwę antykorupcyjną. Ta warstwa tłumaczy komunikację między dwoma systemami, dzięki czemu jeden system pozostanie niezmieniony, podczas gdy drugi może uniknąć naruszania jego projektowania i podejścia technologicznego.
Na powyższym diagramie przedstawiono aplikację z dwoma podsystemami. Podsystem A wywołuje podsystem B za pośrednictwem warstwy antykorupcyjnej. Komunikacja między podsystemem A a warstwą antykorupcyjną zawsze używa modelu danych i architektury podsystemu A. Wywołania z warstwy antykorupcyjnej do podsystemu B są zgodne z modelem danych lub metodami tego podsystemu. Warstwa antykorupcyjna zawiera całą logikę niezbędną do tłumaczenia między dwoma systemami. Warstwę można zaimplementować jako składnik w aplikacji lub jako niezależną usługę.
Problemy i zagadnienia
- Warstwa antykorupcyjna może dodać opóźnienie do wywołań między dwoma systemami.
- Warstwa ochrony przed uszkodzeniem dodaje dodatkową usługę, którą należy zarządzać i obsługiwać.
- Zastanów się, jak będzie skalowana warstwa antykorupcyjna.
- Zastanów się, czy potrzebujesz więcej niż jednej warstwy antykorupcyjnej. Możesz chcieć rozdzielić funkcje na wiele usług przy użyciu różnych technologii lub języków lub mogą istnieć inne powody partycjonowania warstwy ochrony przed uszkodzeniem.
- Zastanów się, w jaki sposób warstwa ochrony przed uszkodzeniem będzie zarządzana w związku z innymi aplikacjami lub usługami. Jak będzie ona zintegrowana z procesami monitorowania, wydawania i konfiguracji?
- Upewnij się, że spójność transakcji i danych jest zachowana i można je monitorować.
- Zastanów się, czy warstwa antykorupcyjna musi obsługiwać całą komunikację między różnymi podsystemami, czy tylko podzbiorem funkcji.
- Jeśli warstwa antykorupcyjna jest częścią strategii migracji aplikacji, rozważ, czy będzie stała, czy zostanie wycofana po przeprowadzeniu migracji wszystkich starszych funkcji.
- Ten wzorzec jest zilustrowany odrębnymi podsystemami powyżej, ale może również mieć zastosowanie do innych architektur usług, takich jak podczas integrowania starszego kodu ze sobą w architekturze monolitycznej.
Kiedy należy używać tego wzorca
Użyj tego wzorca, gdy:
- Planowane jest przeprowadzenie migracji na wielu etapach, ale należy zachować integrację między nowymi i starszymi systemami.
- Co najmniej dwa podsystemy mają różne semantyki, ale nadal muszą się komunikować.
Ten wzorzec może nie być odpowiedni, jeśli nie ma znaczących różnic semantycznych między nowymi i starszymi systemami.
Projekt obciążenia
Architekt powinien ocenić, w jaki sposób wzorzec warstwy przeciwdegradcyjnej może być używany w projekcie obciążenia w celu rozwiązania celów i zasad omówionych w filarach platformy Azure Well-Architected Framework. Przykład:
| Filar | Jak ten wzorzec obsługuje cele filaru |
|---|---|
| Ten wzorzec pomaga zapewnić, że nowy projekt składników pozostaje niezauważony przez starsze implementacje, które mogą mieć różne modele danych lub reguły biznesowe podczas integracji z tymi starszymi systemami i może zmniejszyć dług techniczny w nowych składnikach, jednocześnie obsługując istniejące składniki. - OE:04 Narzędzia i procesy |
Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.