[keyword] 14장 모델의 무결성 유지 (2)
Closed this issue · 3 comments
emiling commented
kth990303 commented
open host service, anti corruption layer 부분이 많이 와닿았습니다.
보통 큰 규모의 서비스일 경우 검색 관련 기능은 별도의 플랫폼으로 분리가 되어 있습니다. 검색 기능은 타 BOUNDED_CONTEXT에 해당되는 모듈에서도 자주 사용합니다. 그렇기 때문에 14장의 초반에 소개됐던 고객-공급자 패턴에 해당되기도 하며, 검색 플랫폼은 Open Host Service에 해당됩니다.
Anticorruption layer는 책의 내용보다는 아래 사진을 보고 많이 공부가 됐던 것 같습니다.
출처: https://learn.microsoft.com/ko-kr/azure/architecture/patterns/anti-corruption-layer
위 사례에도 anticorruption layer가 적용되고, 또 마이그레이션하는 경우에도 anticorruption layer가 적용될 수 있다고 합니다. 레거시를 말라죽이는 스트랭글러 패턴(스프링캠프 2023에 소개됐던 패턴)에서도 레거시와 새로운 영역 간의 소통을 위한 anticorruption layer가 도입될 수 있겠단 생각도 들었네요.
anticorruption layer을 처음에는 타 서비스끼리의 통신을 위한 DTO 관련 layer 정도의 소규모 느낌으로 오해했었는데, 훨씬 더 큰 MSA 및 마이그레이션에서의 개념에 해당되는 경우였다는 걸 깨닫게 됐습니다.
leejaeseung commented
오류 방지 계층
- FACADE 패턴 + Adapter 패턴으로 구현할 수 있다.
FACADE 패턴 : 레거시 인터페이스를 간단한 인터페이스로 변환
Adapter 패턴 : FACADE 패턴으로 단순화된 인터페이스를 클라이언트에 맞게 변환 - 개념 객체의 변환 로직은 복잡하므로 별개로 존재하고, adapter 에는 존재하지 않을 것.
- 번역 간에 기능을 추가할 수 있다. (감사 추적 혹은 디버깅, 로깅 등의 로직?)
외부 시스템과의 관계
- 통합이 정말 필요하지 않다면 SEPARATE WAYS 로 가는게 합리적이다.
- CONTEXT 간의 번역이 애플리케이션의 기능보다 커진다면 CONFORMIST 로 하는게 합리적이다. 단, CONFORMIST 로만 설계해야 한다. 기존 모델을 변경해선 안되고 확장만 하라.
- 기존 시스템을 확장하는 것보다 설계중인 시스템의 기능이 더 복잡해진다면 번역 계층이나 오류 방지 계층을 고려하라. (새로운 BOUNDED CONTEXT 를 가지게끔)
설계 중인 시스템
- BOUNDED CONTEXT 를 설정하기는 쉽지 않기 때문에, 전체 시스템을 BOUNDED CONTEXT 로 정의하고 이를 쪼개나가는게 더 쉽다.
CONTEXT 의 변경
- SEPARATE WAYS → SHARED KERNEL : 공통 부분을 찾아 공통화해감
- SHARED KERNEL → CONTINUOUS INTEGRATION : 공통화를 계속 반복해서 하나의 컨텍스트로 만듬.
- 레거시 시스템의 폐기 (오류 방지 계층) : 레거시의 기능을 신규 서비스에서 점차 구현해나가며 레거시 시스템을 폐기해 나감.
- OPEN HOST SERVICE → PUBLISHED LANGUAGE : 오픈 호스트에 접근하는 서비스가 많아지면 이를 모두에게 공표한다.
JasonYoo1995 commented
- 상류(상위) : API 제공자 (U)
- 하류(하위) : API 호출자 (D)
- CONFORMIST : 상위 서버 모델에 맞추는 하위 서버
- SEPARATE WAYS : 다른 서버 고려하지 않고, 각자 개발
- SHARED KERNEL : 두 서버가 공유하는 공통 모델
- ANTI-CORRUPTION LAYER (ACL) : 하위 쪽에서 사용하는 상위의 변화에 대한 방어
- OPEN HOST SERVICE (OHS) : 상위 쪽 모델에 대한 규약 수립