Merge pull request '결제 전환 목표 아키텍처 정의 (1/2) (2/2)' (#6) from forge/iss-87190c9836ac-attempt-1 into main

.forge/SPRING-ARC-REF-FINAL-1783833422-attempt-1.md

@@ -1,3 +0,0 @@
-# SPRING-ARC-REF-FINAL-1783833422-attempt-1
-
-Forge 이슈 작업 브랜치 `forge/SPRING-ARC-REF-FINAL-1783833422-attempt-1`.

.forge/iss-5a912ed79baf-attempt-3.md

@@ -0,0 +1,3 @@
+# iss-5a912ed79baf-attempt-3
+
+Forge 이슈 작업 브랜치 `forge/iss-5a912ed79baf-attempt-3`.

.forge/iss-87190c9836ac-attempt-1.md

@@ -0,0 +1,3 @@
+# iss-87190c9836ac-attempt-1
+
+Forge 이슈 작업 브랜치 `forge/iss-87190c9836ac-attempt-1`.

docs/architecture/adr-payment-boundary.md

@@ -1,23 +0,0 @@
-# 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.

docs/architecture/package-map.md

@@ -1,7 +1,9 @@
-| 패키지       | 책임                                    | 금지 의존성       |
+# Package Responsibility Map
-|------------|---------------------------------------|------------------|
+
-| controller | 사용자 요청 처리 및 응답 반환                  | domain, repository |
+| Package        | Responsibility                                  | Forbidden Dependencies |
-| service     | 비즈니스 로직 처리 및 트랜잭션 관리            | repository        |
+|----------------|------------------------------------------------|------------------------|
-| repository  | 데이터베이스와의 상호작용                     | domain            |
+| controller     | Handles user input and orchestrates payment    | domain                 |
-| domain      | 비즈니스 규칙 및 도메인 모델 정의             | integration       |
+| service        | Contains business logic for payment processing  | integration            |
-| integration  | 외부 시스템과의 통신 및 데이터 변환          | domain            |
+| repository     | Data access layer for payment records           | service                |
+| domain         | Defines the core domain models and business rules| controller             |
+| integration     | Communicates with external payment gateways     | domain, service        |

docs/architecture/transaction-sequence.md

@@ -1,28 +1,38 @@
+```mermaid
 sequenceDiagram
     participant User
-    participant Controller
+    participant PaymentService
-    participant Service
+    participant PaymentGateway
-    participant Repository
+    participant Database
-    participant ExternalGateway
 
-    User->>Controller: 결제 요청
+    %% Normal Flow
-    Controller->>Service: 결제 처리 요청
+    User->>PaymentService: Initiate Payment
-    Service->>Repository: 트랜잭션 시작
+    PaymentService->>Database: Store Transaction
-    Service->>ExternalGateway: 결제 요청
+    Database-->>PaymentService: Transaction Stored
-    alt 결제 성공
+    PaymentService->>PaymentGateway: Process Payment
-        ExternalGateway-->>Service: 결제 성공 응답
+    PaymentGateway-->>PaymentService: Payment Success
-        Service->>Repository: 트랜잭션 커밋
+    PaymentService->>Database: Update Transaction Status
-        Repository-->>Service: 커밋 완료
+    Database-->>PaymentService: Transaction Updated
-        Service-->>Controller: 결제 완료 응답
+    PaymentService-->>User: Payment Success
-        Controller-->>User: 결제 완료
+
-    else 외부 실패
+    %% External Failure Flow
-        ExternalGateway-->>Service: 결제 실패 응답
+    User->>PaymentService: Initiate Payment
-        Service->>Repository: 트랜잭션 롤백
+    PaymentService->>Database: Store Transaction
-        Repository-->>Service: 롤백 완료
+    Database-->>PaymentService: Transaction Stored
-        Service-->>Controller: 결제 실패 응답
+    PaymentService->>PaymentGateway: Process Payment
-        Controller-->>User: 결제 실패
+    PaymentGateway-->>PaymentService: Payment Failure
-    else DB 실패
+    PaymentService->>Database: Rollback Transaction
-        Service->>Repository: 트랜잭션 롤백
+    Database-->>PaymentService: Transaction Rolled Back
-        Repository-->>Service: 롤백 완료
+    PaymentService-->>User: Payment Failure
-        Service-->>Controller: DB 오류 응답
+
-        Controller-->>User: DB 오류
+    %% DB Failure Flow
+    User->>PaymentService: Initiate Payment
+    PaymentService->>Database: Store Transaction
+    Database-->>PaymentService: Transaction Store Failure
+    PaymentService-->>User: Payment Failure
+
+    %% Commit & Rollback
+    Note over User, PaymentService: 
+    commit --> PaymentService
+    rollback --> PaymentService
+```