도메인 통합 패턴
개요
이 문서는 DTA-WIDE 애플리케이션의 도메인 간 통합 패턴을 정의합니다. 도메인 주도 설계(DDD)에서는 바운디드 컨텍스트 간의 관계를 명확히 정의하는 것이 중요합니다. 이 문서는 시스템에서 사용되는 다양한 통합 패턴과 적용 사례를 설명합니다.
통합 패턴 유형
1. 공유 커널 (Shared Kernel)
정의: 두 개 이상의 팀이 코드베이스의 일부를 공유하는 패턴입니다.
적용 사례:
- 인증(Auth), 사용자(User), IAM 도메인 간에 공통 사용자 ID 및 권한 모델 공유
- 모든 도메인에서 사용하는 기본 엔티티 및 값 객체 정의
구현 방법:
- 공유 라이브러리를 통한 코드 공유
- 명확한 인터페이스 정의
- 변경 관리를 위한 테스트 자동화
2. 고객-공급자 (Customer-Supplier)
정의: 한 컨텍스트(공급자)가 다른 컨텍스트(고객)에 서비스를 제공하는 관계입니다.
적용 사례:
- IAM 도메인(공급자)과 인증(Auth) 도메인(고객)
- 인증(Auth) 도메인(공급자)과 여러 기능 도메인(고객)
구현 방법:
- 명확한 서비스 계약 정의
- 다운스트림 영향을 고려한 API 버전 관리
- 통합 테스트를 통한 계약 검증
3. 준수자 (Conformist)
정의: 한 컨텍스트가 다른 컨텍스트의 모델을 그대로 수용하는 관계입니다.
적용 사례:
- 대부분의 기능 도메인과 로깅, 설정, 데이터베이스 등의 일반 하위 도메인 간의 관계
- 외부 서비스를 그대로 사용하는 경우
구현 방법:
- 공급자의 모델과 인터페이스를 그대로 수용
- 적응에 필요한 어댑터 패턴 활용
- 호환성 유지를 위한 모니터링
4. 부패 방지 계층 (Anti-corruption Layer)
정의: 외부 시스템이나 다른 컨텍스트의 모델이 자신의 모델을 오염시키지 않도록 보호하는 계층입니다.
적용 사례:
- 외부 시스템과의 통합 (예: 결제 시스템, 외부 인증 제공자)
- 레거시 시스템과의 통합
구현 방법:
- 어댑터 및 퍼사드 패턴 사용
- 명확한 변환 로직 정의
- 외부 시스템 변화로부터의 격리
5. 공개 호스트 서비스 (Open Host Service)
정의: 여러 다운스트림 클라이언트가 사용할 수 있는 잘 정의된 서비스를 제공합니다.
적용 사례:
- IAM 도메인이 여러 도메인에 제공하는 권한 검증 서비스
- 공통 데이터 서비스
구현 방법:
- 명확한 공개 API 정의
- 안정적인 계약 유지
- 포괄적인 문서화
6. 게시된 언어 (Published Language)
정의: 여러 컨텍스트 간에 공유되는 공통 언어입니다.
적용 사례:
- 도메인 이벤트 정의
- 서비스 간 메시지 형식
구현 방법:
- 스키마 정의 (JSON Schema, Protocol Buffers 등)
- 버전 관리
- 검증 메커니즘
도메인별 통합 패턴
핵심 도메인 간 통합
| 소스 도메인 | 대상 도메인 | 통합 패턴 | 구현 방법 |
|---|---|---|---|
| Auth | User | 고객-공급자 | REST API |
| Auth | IAM | 고객-공급자 | 내부 서비스 호출 |
| User | IAM | 고객-공급자 | 내부 서비스 호출 |
핵심 도메인과 지원 도메인 간 통합
| 소스 도메인 | 대상 도메인 | 통합 패턴 | 구현 방법 |
|---|---|---|---|
| Auth | Audit | 공개 호스트 서비스 | 이벤트 발행 |
| User | Audit | 공개 호스트 서비스 | 이벤트 발행 |
| IAM | Audit | 공개 호스트 서비스 | 이벤트 발행 |
| User | TimeMachine | 공개 호스트 서비스 | 이벤트 발행 |
| IAM | TimeMachine | 공개 호스트 서비스 | 이벤트 발행 |
| Auth | AccessCode | 고객-공급자 | 내부 서비스 호출 |
도메인과 일반 하위 도메인 간 통합
| 소스 도메인 | 대상 도메인 | 통합 패턴 | 구현 방법 |
|---|---|---|---|
| 모든 도메인 | Logging | 준수자 | 공유 라이브러리 |
| 모든 도메인 | Config | 준수자 | 공유 라이브러리 |
| 모든 도메인 | Database | 준수자 | 공유 라이브러리 |
| 모든 도메인 | ErrorHandling | 준수자 | 공유 라이브러리 |
| 모든 도메인 | Common | 준수자 | 공유 라이브러리 |
외부 시스템 통합
| 내부 도메인 | 외부 시스템 | 통합 패턴 | 구현 방법 |
|---|---|---|---|
| Auth | 외부 OAuth 제공자 | 부패 방지 계층 | API 어댑터 |
| User | 외부 알림 서비스 | 부패 방지 계층 | API 어댑터 |
통합 가이드라인
- 명확한 경계 정의: 각 도메인의 책임과 경계를 명확히 정의하세요.
- 계약 우선 설계: API를 설계할 때 계약을 먼저 정의하고 구현하세요.
- 버전 관리: 모든 통합 지점에 버전 관리를 적용하세요.
- 테스트 자동화: 통합 테스트를 자동화하여 계약 위반을 방지하세요.
- 문서화: 모든 통합 지점을 포괄적으로 문서화하세요.
인증 기반 통합 패턴
User Token Delegation Pattern
정의: 중간 서비스가 사용자를 대신하여 토큰을 관리하고 API 호출을 수행하는 패턴입니다.
적용 사례:
- MCP Server가 Chat Service의 사용자 토큰을 위임받아 DTA-Wide API 호출
- BFF(Backend for Frontend)가 클라이언트 토큰을 관리하여 여러 백엔드 서비스 접근
- API Gateway가 사용자 대신 다운스트림 서비스 호출
구현 방법:
- 세션 기반 토큰 저장 및 관리
- CQRS 기반 토큰 갱신 명령 처리
- 자동 토큰 만료 감지 및 갱신
통합 테이블:
| 소스 서비스 | 대상 서비스 | 통합 패턴 | 구현 방법 | 인증 방식 | 구현 상태 |
|---|---|---|---|---|---|
| Chat Service | MCP Server | 토큰 위임 | 세션 기반 토큰 전달 | User Token | 구현됨 (dta-wide-mcp) |
| MCP Server | DTA-Wide API | 사용자 대리 호출 | Bearer Token | User Token | 구현됨 (dta-wide-mcp) |
| BFF Service | Backend APIs | 토큰 위임 | 자동 토큰 관리 | User Token | 계획 중 |
Service Account Authentication Pattern
정의: 서비스 간 통신에서 서비스 계정을 통한 인증 패턴입니다.
적용 사례:
- 시스템 레벨 데이터 접근 (로그, 메트릭, 설정)
- 배치 작업 및 스케줄링 서비스
- 내부 관리 도구 및 모니터링
구현 방법:
- API Key + JWT Token 조합
- 서비스별 고유 자격 증명
- 자동 토큰 갱신 메커니즘
통합 테이블:
| 소스 서비스 | 대상 서비스 | 통합 패턴 | 구현 방법 | 인증 방식 | 구현 상태 |
|---|---|---|---|---|---|
| MCP Server | Logging API | 서비스 계정 | API Key + JWT | Service Account | 구현됨 (dta-wide-mcp) |
| Monitoring Service | Metrics API | 서비스 계정 | API Key + JWT | Service Account | 계획 중 |
| Batch Service | Data API | 서비스 계정 | API Key + JWT | Service Account | 계획 중 |
이벤트 기반 통합
Cloud Run과 같은 분산 환경에서는 마이크로서비스 간 통합에 이벤트 기반 아키텍처를 권장합니다. 이에 대한 상세한 설명과 구현 가이드는 다음 문서를 참조하세요:
이벤트 기반 통합은 특히 Cloud Run의 스케일링 특성과 잘 맞으며, 서비스 간 결합도를 낮추는 데 도움이 됩니다.
인증 통합 가이드라인
-
패턴 선택 기준: 데이터 접근 유형에 따라 적절한 인증 패턴 선택
- 사용자 개인 데이터: User Token Delegation
- 시스템 레벨 데이터: Service Account Authentication
-
토큰 관리: 중앙화된 토큰 관리 서비스 구축
- 자동 갱신 메커니즘
- 토큰 암호화 저장
- 감사 로깅
-
오류 처리: 인증 실패에 대한 일관된 처리 방식
- 재시도 가능한 오류와 불가능한 오류 구분
- 적절한 백오프 전략 적용
- 사용자 친화적인 오류 메시지
-
보안 고려사항:
- 토큰 생명주기 관리
- 최소 권한 원칙 적용
- 정기적인 보안 감사