diff --git a/.forge/SPRING-ARC-REF-FINAL-1783833422-attempt-1.md b/.forge/SPRING-ARC-REF-FINAL-1783833422-attempt-1.md new file mode 100644 index 0000000..8877b11 --- /dev/null +++ b/.forge/SPRING-ARC-REF-FINAL-1783833422-attempt-1.md @@ -0,0 +1,3 @@ +# SPRING-ARC-REF-FINAL-1783833422-attempt-1 + +Forge 이슈 작업 브랜치 `forge/SPRING-ARC-REF-FINAL-1783833422-attempt-1`. diff --git a/docs/architecture/adr-payment-boundary.md b/docs/architecture/adr-payment-boundary.md new file mode 100644 index 0000000..8cecb88 --- /dev/null +++ b/docs/architecture/adr-payment-boundary.md @@ -0,0 +1,23 @@ +# Architecture Decision Record for Payment Boundary + +## Context +In the context of our ongoing project, we are focused on defining clear boundaries for the payment services. This is crucial to ensure that our architecture remains clean, modular, and maintainable. We need to outline the responsibilities and interactions of various components involved in payment processing. + +## Decision +To establish a clear payment boundary, we will: +1. Define the payment service as a separate module. +2. Use REST APIs for communication between the payment service and other microservices. +3. Ensure that any sensitive operations, like payment processing, are encapsulated within the payment service and not exposed directly to clients. +4. Implement service-level security to protect payment information. + +## Alternatives +- **Monolithic Approach**: Keeping all payment processing logic within a single application. This is easier to manage initially but leads to tight coupling. +- **Event-Driven Architecture**: Using a messaging system for inter-service communication. This would add complexity in terms of managing events and message reliability, but would result in a more decoupled system. + +## Consequences +By defining clear boundaries for payment processing: +- We achieve separation of concerns, which improves maintainability. +- We can independently scale the payment service based on demand. +- Security risks are minimized as sensitive operations are isolated. + +This decision will guide the development and integration efforts moving forward, especially when considering transaction management and error handling. \ No newline at end of file diff --git a/docs/architecture/package-map.md b/docs/architecture/package-map.md new file mode 100644 index 0000000..fcfca11 --- /dev/null +++ b/docs/architecture/package-map.md @@ -0,0 +1,7 @@ +| 패키지 | 책임 | 금지 의존성 | +|------------|---------------------------------------|------------------| +| controller | 사용자 요청 처리 및 응답 반환 | domain, repository | +| service | 비즈니스 로직 처리 및 트랜잭션 관리 | repository | +| repository | 데이터베이스와의 상호작용 | domain | +| domain | 비즈니스 규칙 및 도메인 모델 정의 | integration | +| integration | 외부 시스템과의 통신 및 데이터 변환 | domain | \ No newline at end of file diff --git a/docs/architecture/transaction-sequence.md b/docs/architecture/transaction-sequence.md new file mode 100644 index 0000000..e31aebd --- /dev/null +++ b/docs/architecture/transaction-sequence.md @@ -0,0 +1,28 @@ +sequenceDiagram + participant User + participant Controller + participant Service + participant Repository + participant ExternalGateway + + User->>Controller: 결제 요청 + Controller->>Service: 결제 처리 요청 + Service->>Repository: 트랜잭션 시작 + Service->>ExternalGateway: 결제 요청 + alt 결제 성공 + ExternalGateway-->>Service: 결제 성공 응답 + Service->>Repository: 트랜잭션 커밋 + Repository-->>Service: 커밋 완료 + Service-->>Controller: 결제 완료 응답 + Controller-->>User: 결제 완료 + else 외부 실패 + ExternalGateway-->>Service: 결제 실패 응답 + Service->>Repository: 트랜잭션 롤백 + Repository-->>Service: 롤백 완료 + Service-->>Controller: 결제 실패 응답 + Controller-->>User: 결제 실패 + else DB 실패 + Service->>Repository: 트랜잭션 롤백 + Repository-->>Service: 롤백 완료 + Service-->>Controller: DB 오류 응답 + Controller-->>User: DB 오류 \ No newline at end of file