결제 전환 목표 아키텍처 정의 #1
4 changed files with 49 additions and 0 deletions
3
.forge/SPRING-ARC-VERIFIED-1783826844-attempt-1.md
Normal file
3
.forge/SPRING-ARC-VERIFIED-1783826844-attempt-1.md
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
# SPRING-ARC-VERIFIED-1783826844-attempt-1
|
||||||
|
|
||||||
|
Forge 이슈 작업 브랜치 `forge/SPRING-ARC-VERIFIED-1783826844-attempt-1`.
|
||||||
14
docs/architecture/adr-payment-boundary.md
Normal file
14
docs/architecture/adr-payment-boundary.md
Normal file
|
|
@ -0,0 +1,14 @@
|
||||||
|
# Architectural Decision Record (ADR) for Payment System Boundary
|
||||||
|
|
||||||
|
## Context
|
||||||
|
The goal is to define a robust architecture for the payment processing system within our application. This system will handle various payment methods and ensure the accuracy and security of transactions.
|
||||||
|
|
||||||
|
## Decision
|
||||||
|
We have decided to establish clear boundaries between different components of the payment system, particularly between the controller, service, repository, domain, and integration layers. This separation will enhance maintainability and scalability.
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
- Keeping all payment logic within the controller layer (rejected due to tight coupling and low maintainability).
|
||||||
|
- Using a monolithic approach without clear boundaries (rejected for potential scalability issues).
|
||||||
|
|
||||||
|
## Consequences
|
||||||
|
Implementing this decision will require careful adherence to the boundaries to ensure no direct dependencies occur between layers, thus preserving the integrity and independence of each component. This might introduce some initial overhead, but will pay off in the long run with a cleaner architecture.
|
||||||
7
docs/architecture/package-map.md
Normal file
7
docs/architecture/package-map.md
Normal file
|
|
@ -0,0 +1,7 @@
|
||||||
|
| 패키지 | 책임 | 금지 의존성 |
|
||||||
|
|-------------|-------------------------------------------|---------------------|
|
||||||
|
| controller | 사용자 요청 처리 및 응답 반환 | domain, service |
|
||||||
|
| service | 비즈니스 로직 처리 및 트랜잭션 관리 | repository |
|
||||||
|
| repository | 데이터베이스와의 상호작용 | domain |
|
||||||
|
| domain | 비즈니스 규칙 및 도메인 모델 정의 | integration |
|
||||||
|
| integration | 외부 시스템과의 통합 (예: 결제 게이트웨이) | domain, service |
|
||||||
25
docs/architecture/transaction-sequence.md
Normal file
25
docs/architecture/transaction-sequence.md
Normal file
|
|
@ -0,0 +1,25 @@
|
||||||
|
```mermaid
|
||||||
|
sequenceDiagram
|
||||||
|
participant User
|
||||||
|
participant Controller
|
||||||
|
participant Service
|
||||||
|
participant Repository
|
||||||
|
participant PaymentGateway
|
||||||
|
|
||||||
|
User->>Controller: 결제 요청
|
||||||
|
Controller->>Service: 결제 처리 요청
|
||||||
|
Service->>Repository: 트랜잭션 시작
|
||||||
|
alt 정상 흐름
|
||||||
|
Service->>PaymentGateway: 결제 요청
|
||||||
|
PaymentGateway-->>Service: 결제 성공
|
||||||
|
Service->>Repository: 트랜잭션 커밋
|
||||||
|
else 외부 실패
|
||||||
|
Service->>PaymentGateway: 결제 요청
|
||||||
|
PaymentGateway-->>Service: 결제 실패
|
||||||
|
Service->>Repository: 트랜잭션 롤백
|
||||||
|
else DB 실패
|
||||||
|
Service->>Repository: 트랜잭션 시작
|
||||||
|
Service->>Repository: DB 오류 발생
|
||||||
|
Service->>Repository: 트랜잭션 롤백
|
||||||
|
end
|
||||||
|
```
|
||||||
Loading…
Add table
Add a link
Reference in a new issue