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. Po raz pierwszy opisał go Eric Evans w dokumencie Domain-Driven Design (Projekt kierowany przez domenę).
Kontekst i problem
Większość aplikacji zależy od innych systemów w zakresie pewnych danych lub funkcji. Przykładowo gdy starsza aplikacja jest migrowana do nowoczesnego systemu, nadal może potrzebować dotychczasowych, starszych zasobów. Nowe funkcje muszą mieć możliwość wywoływania starszego systemu. Jest tak w szczególności w przypadku migracji stopniowych, w których różne funkcje większej aplikacji są w miarę upływu czasu przenoszone do nowoczesnego systemu.
Starsze systemy często 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ą w istotny sposób różnić się od tych, które zastosowano w bardziej nowoczesnych systemach. Aby współdziałać ze starszym systemem, nowa aplikacja może musieć obsługiwać przestarzałą infrastrukturę, protokoły, modele danych, interfejsy API i inne funkcje, które inaczej nie znalazłyby się w nowoczesnej aplikacji.
Obsługa dostępu między nowym i starszym systemem może wymusić na nowym systemie zgodność z co najmniej częścią interfejsów API starszego systemu i innej semantyki. Jeśli te starsze funkcje mają problemy z jakością, ich obsługa „degraduje” to, co inaczej mogłoby być przejrzyście 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 przeciwdegradacyjna zawiera całą logikę niezbędną do wykonywania tłumaczeń między dwoma systemami. Warstwę tę można zaimplementować jako składnik w aplikacji lub jako niezależną usługę.
Problemy i kwestie do rozważenia
- Warstwa przeciwdegradacyjna może dodawać opóźnienie do wywołań między dwoma systemami.
- Warstwa przeciwdegradacyjna dodaje kolejną usługę, którą trzeba obsługiwać i zarządzać.
- Przemyśl sposób, w jaki Twoja warstwa przeciwdegradacyjna ma być skalowana.
- Pomyśl, czy potrzebujesz więcej niż jednej warstwy przeciwdegradacyjnej. Możesz zechcieć rozłożyć funkcjonalność na wiele usług korzystających z różnych technologii lub języków, ale mogą być też inne przyczyny podzielenia warstwy przeciwdegradacyjnej.
- Przemyśl sposób zarządzania warstwą przeciwdegradacyjną w związku z innymi aplikacjami lub usługami. Jak zostanie ona zintegrowana z procesami monitorowania, wydawania i konfigurowania?
- Upewnij się, że zachowana zostanie spójność transakcji i danych oraz że da się ją 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 używać tego wzorca
Użyj tego wzorca, gdy:
- Migracja jest planowana na wiele etapów, ale integracja między nowym i starszym systemem musi być zachowana.
- Co najmniej dwa podsystemy mają różne semantyki, ale nadal muszą się komunikować.
Ten wzorzec może nie być odpowiedni, gdy między nowym i starszym systemem nie ma znaczących różnic w semantyce.
Projekt obciążenia
Architekt powinien ocenić, w jaki sposób wzorzec warstwy antykorupcyjnej 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. Na przykład:
| Filar | Jak ten wzorzec obsługuje cele filaru |
|---|---|
| Doskonałość operacyjna pomaga zapewnić jakość obciążeń dzięki ustandaryzowanym procesom i spójności zespołu. | 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.