결제 전환 목표 아키텍처 정의 #2
1 changed files with 11 additions and 7 deletions
|
|
@ -1,15 +1,19 @@
|
|||
# 결제 전환 목표 아키텍처 결정 기록
|
||||
# ADR: Payment Boundary
|
||||
|
||||
## Context
|
||||
결제 시스템의 경계를 정의하고, 결제 전환 목표를 달성하기 위한 아키텍처를 설계한다.
|
||||
결제 시스템을 구현하는 데 있어 도메인 아이템과 외부 결제 게이트웨이 간의 경계를 명확히 하는 것이 중요합니다. 이를 통해 결제 처리에 대한 책임을 잘 정의하고, 도메인 로직과 외부 종속성 간의 결합도를 최소화할 수 있습니다.
|
||||
|
||||
## Decision
|
||||
결제 전환 목표를 위해 마이크로서비스 아키텍처를 채택하고, 각 서비스의 책임을 명확히 한다.
|
||||
도메인 모델은 결제 게이트웨이에 대한 직접 참조를 피하고, 대신 포트 인터페이스를 통해 결제 관련 요청을 처리하도록 합니다. 이를 통해 결제 프로세스를 더 유연하게 관리하고, 다양한 외부 결제 제공자와의 통합을 용이하게 합니다.
|
||||
|
||||
## Alternatives
|
||||
1. 모놀리식 아키텍처
|
||||
2. 서버리스 아키텍처
|
||||
1. **직접 의존**: 도메인 모델이 결제 게이트웨이에 직접 의존하게 하는 방식
|
||||
- 장점: 구현이 단순하고 빠름
|
||||
- 단점: 결제 제공자 변경 시 도메인 모델 수정 필요
|
||||
|
||||
2. **포트 인터페이스 사용 (선택한 안)**: 도메인 모델과 외부 시스템 간의 의존성을 포트 인터페이스로 분리
|
||||
- 장점: 도메인 모델의 독립성 유지, 다양한 결제 제공자와의 통합 용이
|
||||
- 단점: 초기 구현이 더 복잡할 수 있음
|
||||
|
||||
## Consequences
|
||||
- 마이크로서비스 아키텍처는 서비스 간의 독립성을 높이며, 배포와 확장이 용이하다.
|
||||
- 그러나 서비스 간의 통신과 데이터 일관성 관리가 복잡해질 수 있다.
|
||||
이 결정을 통해 코드베이스의 유연성과 유지 보수성이 증가할 것이며, 새로운 결제 제공자 추가에 따른 프로젝트의 전체적인 작업량이 줄어들 것입니다. 또한, 도메인 모델은 요구 사항 변경 시 더 적은 영향 만큼의 수정으로 대응할 수 있게 됩니다.
|
||||
Loading…
Add table
Add a link
Reference in a new issue