9.5 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created, last_reviewed, status, confidence, vendor, author, published
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | last_reviewed | status | confidence | vendor | author | published | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| official-doc / Anti-Corruption Layer Pattern (Microsoft Azure Architecture Center) | official-doc | https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer |
|
|
|
2026-05-28 | 2026-05-28 | raw | high | Microsoft Azure Architecture Center | claytonsiemens77 | 2022-07-28 |
Anti-Corruption Layer Pattern (Microsoft Azure Architecture Center)
Layer:
raw/official-docs/— Microsoft Azure Architecture Center 공식 클라우드 설계 패턴 레퍼런스의 원문 발췌·출처 기록. 검증된 요약은/ingest후wiki/concepts/에source-summary-template형식으로 별도 작성. 원본은 raw에 영구 보관.
Parent / 활용 branch
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-boundary-validation-mapping-contract | outbound HTTP / external dependency 응답 → domain 변환이 본 branch 의 mapper 정의 안에 포함된다는 scope 명확화 (블라인드 B7). ACL 패턴이 동일한 mapper 책임 (변환 + 검증 + 정규화) 을 inbound 가 아닌 outbound-response 방향에 적용한다는 근거 |
출처 / Source
- 원본 URL: https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer
- 아카이브 URL: (미제공)
- 저자 / 조직: claytonsiemens77 / Microsoft Azure Architecture Center
- 발행일: 2022-07-28 (최종 업데이트: 2025-12-09)
- 마지막 확인일: 2026-05-28
왜 저장했는지 / Why archived
feature-boundary-validation-mapping-contract branch 의 mapper 범위가 inbound REST 경계만 명시하고 outbound HTTP adapter 응답 → domain 변환 (블라인드 B7) 을 다루지 않는다. Microsoft Azure Architecture Center 의 ACL 패턴 공식 정의는 "다른 의미론(semantics)을 가진 두 서브시스템 사이" 에서 번역 책임을 가지는 계층을 normative 하게 정의하므로, outbound-response 방향 mapper 도 동일한 boundary mapper 범위 안에 포함된다는 공식 근거로 사용한다.
핵심 인용 / Key quotes (verbatim)
[§intro] "Implement a façade or adapter layer between different subsystems that don't share the same semantics. This layer translates requests that one subsystem makes to the other subsystem. Use this pattern to ensure that an application's design isn't limited by dependencies on outside subsystems. This pattern was first described by Eric Evans in Domain-Driven Design." (line 7 in fetched text)
[§Context and problem] "Maintaining access between new and legacy systems can force the new system to adhere to at least some of the legacy system's APIs or other semantics. When these legacy features have quality issues, supporting them "corrupts" what might otherwise be a cleanly designed modern application." (line 15 in fetched text)
[§Solution] "Isolate the different subsystems by placing an anti-corruption layer between them. This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach." (line 21 in fetched text)
[§Solution] "The anti-corruption layer contains all of the logic necessary to translate between the two systems. The layer can be implemented as a component within the application or as an independent service." (line 23 in fetched text — extracted from the longer paragraph)
[§Issues and considerations] "The anti-corruption layer might add latency to calls made between the two systems." (line 27 in fetched text)
[§When to use this pattern] "Two or more subsystems have different semantics, but still need to communicate." (line 42 in fetched text)
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| MS-ACL-C1 | ACL 은 서로 다른 의미론(semantics)을 공유하지 않는 서브시스템 사이에 위치하는 façade 또는 adapter 계층이다 | [§intro] "Implement a façade or adapter layer between different subsystems that don't share the same semantics. This layer translates requests that one subsystem makes to the other subsystem." | official-vendor-doc |
두 서브시스템이 서로 다른 데이터 모델·프로토콜·도메인 의미론을 사용하는 모든 통합 경계 | 특정 구현 기술(언어·프레임워크·라이브러리) 선택; inbound/outbound 방향 중 어느 한 쪽만 해당된다는 주장 |
| MS-ACL-C2 | ACL 은 두 시스템 간 통신을 번역(translate)하며, 한 시스템이 변경되지 않아도 되고 다른 시스템도 설계를 타협하지 않아도 된다 | [§Solution] "This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach." | official-vendor-doc |
legacy 연동, 외부 서비스 연동, 마이크로서비스 간 모델 분리 | 번역 정확성의 단위 테스트가 자동 보장됨; 번역 과정에서 정규화·마스킹 책임이 포함됨을 직접 말하지 않음 |
| MS-ACL-C3 | ACL 은 두 시스템 간 번역에 필요한 모든 로직을 포함하며, 애플리케이션 내 컴포넌트 또는 독립 서비스로 구현 가능하다 | [§Solution] "The anti-corruption layer contains all of the logic necessary to translate between the two systems. The layer can be implemented as a component within the application or as an independent service." | official-vendor-doc |
단일 모놀리식 앱 내 인-프로세스 ACL, 별도 마이크로서비스형 ACL 모두 | ACL 이 반드시 별도 배포 단위여야 한다는 주장; ACL 안에서의 세부 레이어 분할 방법 |
| MS-ACL-C4 | ACL 은 두 시스템 간 호출에 레이턴시를 추가할 수 있다 | [§Issues and considerations] "The anti-corruption layer might add latency to calls made between the two systems." | official-vendor-doc |
동기 HTTP 호출 경로에 ACL 이 인-프로세스 또는 별도 서비스로 위치하는 경우 | 레이턴시가 허용 불가 수준임; 비동기 메시지 기반 통합에서 레이턴시 영향이 동일함 |
| MS-ACL-C5 | ACL 패턴은 두 개 이상의 서브시스템이 서로 다른 의미론을 가지지만 여전히 통신해야 할 때 사용한다 | [§When to use this pattern] "Two or more subsystems have different semantics, but still need to communicate." | official-vendor-doc |
외부 API · legacy 시스템 · 다른 bounded context 와의 통합 | 의미론 차이가 없는 내부 서비스 간 통신; ACL 이 성능 병목인 경우의 적용 판단 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
MS-ACL-C1: ACL 이 공식 클라우드 아키텍처 패턴으로 정의되며, 다른 의미론을 가진 서브시스템 간 경계에 놓인다는 사실MS-ACL-C2: ACL 의 핵심 책임이 "번역(translate)"이며 한쪽 시스템의 설계 순수성을 보호한다는 사실MS-ACL-C3: ACL 이 인-프로세스 컴포넌트 또는 독립 서비스 두 가지 형태로 모두 구현 가능하다는 사실MS-ACL-C4: ACL 도입 시 레이턴시 추가 가능성이 공식 고려사항임MS-ACL-C5: 사용 시점 조건 (서로 다른 semantics + 통신 필요)
- 이 자료가 증명하지 않는 것:
- outbound HTTP adapter 응답 → domain 변환이 반드시 동일 mapper 로 처리되어야 한다는 구체적 구현 지침
- ACL 내부에서 normalization·masking·public field selection 이 포함되어야 한다는 직접 진술
- Spring Boot / Hexagonal architecture 의 Port-Adapter 구조와 ACL 의 정확한 대응 관계
- 단방향(inbound-only 또는 outbound-only) ACL 과 양방향 ACL 의 선택 기준
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
feature-boundary-validation-mapping-contract의 mapper 가 ACL 의 "translate" 책임을 outbound-response 방향에서도 수행하는지 ArchUnit rule + integration test 로 검증 필요- ACL 을 인-프로세스 컴포넌트(
MS-ACL-C3)로 구현할 때 ca-skeleton 의 Hexagonal port/adapter 패키지 구조와 정합성 확인 필요
메모 / Notes
- 본 패턴은 Eric Evans의 Domain-Driven Design (2003) 에서 기원. Microsoft Azure Architecture Center 는 이를 클라우드 설계 패턴 카탈로그에 수록한 공식 벤더 문서.
MS-ACL-C2("the other can avoid compromising its design") 는feature-boundary-validation-mapping-contract의 D1/D7 결정 (모든 경계에 mapper 책임) 을 지지하나, 본 문서가 직접적으로 inbound + outbound 양방향 mapper 강제를 명시하지 않으므로 D1/D7 는 여전히 Hexagonal architecture raw 별도 보강 권장.- 추가로 봐야 할 동일 출처 페이지: Strangler Fig pattern (
https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig), Messaging Bridge pattern (https://learn.microsoft.com/en-us/azure/architecture/patterns/messaging-bridge)
Related / 관련
- 같은 주제 DDD 기원 문서: raw/official-docs/arch-hexagonal-cockburn, raw/official-docs/arch-clean-architecture-uncle-bob
- Hexagonal port-adapter 구조 적용 사례: raw/official-docs/hexagonal-thombergs-buckpal-github
- 이 자료를 인용한 wiki 요약: (미생성 —
/ingest후wiki/concepts/anti-corruption-layer.md예정)