결제 전환 목표 아키텍처 정의 (1/2) (SPRING-ARC-REF-FINAL-1783833422)
All checks were successful
ci / test (pull_request) Successful in 7s
All checks were successful
ci / test (pull_request) Successful in 7s
This commit is contained in:
parent
c066f17f9e
commit
90ae4cf463
1 changed files with 9 additions and 7 deletions
|
|
@ -1,15 +1,17 @@
|
||||||
# 결제 전환 목표 아키텍처 결정 기록
|
# 결제 경계 아키텍처 결정 기록
|
||||||
|
|
||||||
## Context
|
## Context
|
||||||
결제 시스템의 아키텍처를 정의하여 외부 결제 게이트웨이와의 통신을 효율적으로 처리하고, 도메인 로직과의 의존성을 최소화하기 위한 목표.
|
이 문서는 결제 시스템의 아키텍처를 정의하며, 외부 결제 게이트웨이에 대한 통합 방식을 설명합니다. 이 시스템은 다양한 결제 방법을 지원하여, 고객이 쉽게 결제를 할 수 있도록 합니다. 제약조건으로는 도메인에서 어댑터를 직접 참조하지 않고, 포트 인터페이스를 사용해야 합니다.
|
||||||
|
|
||||||
## Decision
|
## Decision
|
||||||
도메인 계층에서 외부 결제 게이트웨이를 직접 참조하지 않고, 포트 인터페이스를 통해 의존성을 관리하기로 결정.
|
결제 시스템은 외부 결제 게이트웨이와의 통신을 위해 포트-어댑터 패턴을 활용합니다. 도메인 계층은 포트를 통해 외부 시스템과 상호 작용하고, 어댑터는 실제 통신 구현을 담당합니다. 이를 통해 도메인 계층의 독립성을 유지하고, 시스템의 확장성을 높입니다.
|
||||||
|
|
||||||
## Alternatives
|
## Alternatives
|
||||||
1. 도메인에서 직접 외부 결제 게이트웨이를 참조하는 방법
|
- 직접적인 의존성: 외부 결제 게이트웨이에 직접 의존하는 접근 방식은 테스트와 유지보수를 어렵게 만듭니다. 이는 나중에 변경 시에 시스템 전체를 수정해야 할 수 있습니다.
|
||||||
2. 서비스 계층에서 외부 결제 게이트웨이를 참조하는 방법
|
- 내부 구현: 모든 결제 기능을 내부에서 직접 처리하는 방법도 있지만, 이는 다양한 결제 수단을 관리하기 위한 비효율적 접근이 될 수 있습니다.
|
||||||
|
|
||||||
## Consequences
|
## Consequences
|
||||||
- 도메인 계층의 독립성을 유지할 수 있으며, 테스트 용이성이 증가함.
|
포트-어댑터 패턴을 사용함으로써:
|
||||||
- 외부 결제 게이트웨이 변경 시 도메인 로직에 영향을 미치지 않음.
|
- 시스템의 유연성이 증가하고, 새로운 결제 수단을 추가하기 쉬워집니다.
|
||||||
|
- 더 나은 테스트 가능성을 제공하여, 도메인 계층을 독립적으로 테스트할 수 있습니다.
|
||||||
|
- 외부 결제 게이트웨이의 변경 시, 도메인 계층에 미치는 영향을 최소화할 수 있습니다.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue