마이그레이션 상황
오래된 모놀리식 어플리케이션을 마이크로서비스로 마이그레이션하려 함
보통 이런 상황에서는
이 둘 모두를 한꺼번에 하려고 할 것임
하지만 마이그레이션을 진행한다고 해서 모든 개발을 중단할 순 없음.
즉 운영중인 서비스는 계속 고도화 및 확장 등이 일어날것임
이렇게 될 경우, 하나씩 마이크로서비스를 만들어가면서 현재 돌아가는 모놀리식 어플리케이션과 연동시킬거임 (마이크로서비스가 전부 모놀리식 어플리케이션을 대체할 때 까지)
하지만, 한번에 완전히 전환하지 않으면 마이크로서비스들이 저 현대화 전 레거시 어플리케이션에 의존하게됨(API, Data 등에 대해서)
이러면 어플리케이션 현대화의 의미가 퇴색됨
이러한 상황을 방지하기 위해
손상 방지 계층 패턴이 존재함
이 패턴은 이전 시스템과 새 시스템의 어댑터 기능을 하는 서비스를 통해 새로 작성한 마이크로서비스와 모놀리식(레거시) 어플리케이션이 직접 연결되는것을 방지함
서로 통신을 할 때 무조건 손상 방지 계층을 지나게 함으로써, 이 둘 간 의존성을 없에게 되는게 핵심
일반적으론 마이그레이션 완료 후에 어댑터를 없엘거임
하지만 마이그레이션 이후에도 레거시 코드는 남아있을 수 있음.
(완전히 레거시 코드를 제거할 수 없는 상황도 존재할 수 있음)
이런 상황에서, 손상 방지 계층을 남긴다면, 이를 통해 레거시 시스템과 새로운 시스템이 통신하게 하여 새로운 시스템의 손상을 방지함
만능은 아님. 생각해 볼 요소들이 있음
손상 방지 어댑터 또한 개발, 테스트 ,배포되어야 하는 서비스임
개발해야 할 요소가 증가함
손상 방지 계층의 존재 자체가 통신에 하나의 계층이 추가되는것을 의미
이는 즉 추가적 오버헤드의 발생을 의미함