동일한 의미 체계를 공유하지 않는 서로 다른 하위 시스템 간에 외관 또는 어댑터 계층을 구현합니다. 이 계층은 한 하위 시스템이 다른 하위 시스템에 만드는 요청을 변환합니다. 이 패턴을 사용하여 외부 하위 시스템에 대한 종속성이 애플리케이션의 디자인을 제한하지 않도록 합니다. Eric Evans는 Domain-Driven Design: Tackling Complexity in the Heart of Software에서 이 패턴을 처음 설명했습니다.
컨텍스트 및 문제점
대부분의 애플리케이션은 일부 데이터 또는 기능에 다른 시스템을 사용합니다. 예를 들어 레거시 애플리케이션을 최신 시스템으로 마이그레이션하는 경우 애플리케이션은 기존 레거시 리소스를 계속 사용할 수 있습니다. 새 기능은 레거시 시스템을 호출할 수 있어야 합니다. 이 기능은 시간이 지남에 따라 더 큰 애플리케이션의 다양한 기능을 최신 시스템으로 이동하는 점진적 마이그레이션에 특히 중요합니다.
이러한 레거시 시스템에는 종종 복잡 한 데이터 스키마 또는 사용되지 않는 API와 같은 품질 문제가 있습니다. 레거시 시스템에서 사용하는 기능과 기술은 최신 시스템과 크게 다를 수 있습니다. 레거시 시스템과 상호 운용하기 위해 새 애플리케이션은 오래된 인프라, 프로토콜, 데이터 모델, API 또는 최신 애플리케이션에 추가하지 않는 기타 기능을 지원해야 할 수 있습니다.
새 시스템과 레거시 시스템 간의 액세스를 유지 관리하는 경우 새 시스템이 레거시 시스템의 API 또는 기타 의미 체계 중 일부를 준수하도록 강제합니다. 이러한 레거시 기능에 품질 문제가 있는 경우 이 지원은 새로 디자인된 최신 애플리케이션일 수 있는 기능을 손상합니다.
개발 팀이 제어하지 않는 외부 시스템에서도 비슷한 문제가 발생할 수 있습니다.
해결 방법
손상 방지 계층을 배치하여 서로 다른 하위 시스템을 격리합니다. 이 계층은 두 시스템 간의 통신을 변환합니다. 이 방법을 사용하면 다른 시스템의 설계 및 기술 접근 방식을 손상시키지 않고 한 시스템을 변경하지 않고 유지할 수 있습니다.
이 아키텍처의 Visio 파일을 다운로드하십시오.
다이어그램은 두 개의 하위 시스템이 있는 애플리케이션을 보여 줍니다. 하위 시스템 A는 손상 방지 계층을 통해 하위 시스템 B를 호출합니다. 하위 시스템 A와 손상 방지 계층 간의 통신은 항상 하위 시스템 A의 데이터 모델과 아키텍처를 사용합니다. 손상 방지 계층에서 하위 시스템 B로의 호출은 해당 하위 시스템의 데이터 모델 또는 메서드를 준수합니다. 손상 방지 계층에는 두 시스템 간에 변환하는 데 필요한 모든 논리가 포함됩니다. 계층을 애플리케이션 내의 구성 요소 또는 독립 서비스로 구현할 수 있습니다.
문제 및 고려 사항
이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.
손상 방지 계층은 두 시스템 간의 호출에 대기 시간을 추가합니다.
손상 방지 계층은 관리 및 유지 관리해야 하는 추가 서비스를 추가합니다.
손상 방지 계층을 어떻게 확장할지 고려하세요.
둘 이상의 손상 방지 계층이 필요한지 여부를 고려합니다. 예를 들어 다양한 기술 또는 언어를 사용하는 여러 서비스로 기능을 분해할 수 있습니다.
다른 애플리케이션 또는 서비스와 관련하여 손상 방지 계층을 관리하는 방법과 모니터링, 릴리스 및 구성 프로세스에 통합하는 방법을 고려합니다.
트랜잭션 및 데이터 일관성을 유지 관리하고 모니터링해야 합니다.
손상 방지 계층이 서로 다른 하위 시스템 간의 모든 통신을 처리해야 하는지 또는 기능의 하위 집합만 처리해야 하는지 고려합니다.
손상 방지 계층이 애플리케이션 마이그레이션 전략의 일부인 경우 영구 계층인지 또는 모든 레거시 기능을 마이그레이션한 후 사용 중지할지 여부를 고려합니다.
이전 다이어그램에서는 고유한 하위 시스템을 사용하여 이 패턴을 설명하지만 모놀리식 아키텍처의 레거시 코드 통합과 같은 다른 서비스 아키텍처에도 적용할 수 있습니다.
손상 방지 계층은 신뢰 수준이 다를 수 있는 시스템을 중재하므로 이 경계에서 입력 유효성 검사 및 삭제를 적용하는 것이 좋습니다.
상관 관계 ID 및 구조적 로깅을 비롯한 관찰 가능성을 계획하여 번역 실패를 진단합니다.
이 패턴을 사용하는 경우
다음 경우에 이 패턴을 사용합니다.
여러 단계에서 마이그레이션이 수행되도록 계획하지만 새 시스템과 레거시 시스템 간의 통합을 유지 관리해야 합니다.
둘 이상의 하위 시스템에는 서로 다른 의미 체계가 있지만 통신해야 합니다.
이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.
- 새 시스템과 레거시 시스템은 의미 체계에 큰 차이가 없습니다. 이 시나리오에서는 반부패 계층을 번역 논리에 집중하는 것이 중요합니다. 계층에 비즈니스 규칙 또는 오케스트레이션을 배치하지 않습니다.
워크로드 디자인
워크로드 설계에서 손상 방지 계층(Anti-Corruption Layer) 패턴을 사용하여 Azure Well-Architected Framework 핵심 원칙에서 다루는 목표와 원칙을 충족하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.
| 핵심 요소 | 이 패턴으로 핵심 목표를 지원하는 방법 |
|---|---|
| 운영 우수성은 표준화된 프로세스와 팀 응집력을 통해 워크로드 품질을 제공하는 데 도움이 됩니다. | 이 패턴은 이러한 레거시 시스템과 통합할 때 다른 데이터 모델 또는 비즈니스 규칙을 가질 수 있는 레거시 구현에 의해 새 구성 요소 디자인이 영향을 받지 않도록 하는 데 도움이 됩니다. 기존 구성 요소를 지원하면서 새 구성 요소의 기술 문제를 줄일 수 있습니다. - OE:04 도구 및 프로세스 - OE:07 모니터링 시스템 |
이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.
예시
이 패턴은 개념적이며 도메인 기반 디자인 소프트웨어 개발 접근 방식에서 비롯됩니다. Azure API Management 또는 Azure Functions 같은 Azure 서비스는 프로토콜 처리 및 번역에 도움이 될 수 있지만 손상 방지 계층의 핵심 목적은 특정 제품 선택을 규정하지 않고 도메인 모델을 보호하는 것입니다.
다음 예제에서 API Management는 외부 노출 및 프로토콜 문제를 처리합니다. Azure Functions 새 시스템과 레거시 시스템 간의 도메인 매핑을 통해 손상 방지 계층을 구현합니다. Azure Monitor 및 Application Insights는 두 하위 시스템 간의 변환 성공 및 대기 시간을 추적하는 데 필요한 가시성을 제공합니다.
이 동기 요청-응답 모델 외에도 손상 방지 계층은 비동기 이벤트 기반 접근 방식을 사용할 수도 있습니다. 계층은 Azure Service Bus, Azure Event Grid 또는 Azure Event Hubs 사용하여 최신 도메인을 레거시 시스템의 처리량 제약 조건과 분리하여 높은 처리량 또는 고도로 분리된 워크로드에 대한 메시지 기반 변환을 허용합니다.
다음 단계
분산 트랜잭션을 관리하고 보상 트랜잭션 패턴 및 Saga 분산 트랜잭션 패턴과 같은 데이터 일관성 을 유지하는 데 도움이 되는 클라우드 디자인 패턴을 살펴봅니다.
손상 방지 계층은 단일 실패 지점이 될 수 있으므로 다시 시도 패턴, 회로 차단기 패턴, 격벽 패턴 및 상태 엔드포인트 모니터링 패턴을 사용하여 복원력을 계획합니다.