결제 전환 목표 아키텍처 정의 (2/2) #3
2 changed files with 20 additions and 0 deletions
3
.forge/iss-f2a42175edbf-attempt-1.md
Normal file
3
.forge/iss-f2a42175edbf-attempt-1.md
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
# iss-f2a42175edbf-attempt-1
|
||||||
|
|
||||||
|
Forge 이슈 작업 브랜치 `forge/iss-f2a42175edbf-attempt-1`.
|
||||||
17
docs/architecture/adr-payment-boundary.md
Normal file
17
docs/architecture/adr-payment-boundary.md
Normal file
|
|
@ -0,0 +1,17 @@
|
||||||
|
# ADR for Payment Boundary
|
||||||
|
|
||||||
|
## Context
|
||||||
|
In the context of our application, we need to define a clear boundary for payment processing to ensure that the payment system is encapsulated and communicates efficiently with other parts of the application. This includes defining how the payment service interacts with controllers, repositories, and external payment gateways.
|
||||||
|
|
||||||
|
## Decision
|
||||||
|
The decision is to implement a payment processing boundary within the architecture that clearly separates the payment logic from other business logic. This boundary will enforce strict interaction protocols between the payment service and other components of the system.
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
1. **No clear boundary**: Allowing all services to access payment logic directly.
|
||||||
|
- **Consequences**: Increased coupling and potential for bugs due to uncoordinated changes.
|
||||||
|
|
||||||
|
2. **Tight coupling with external services**: Directly integrate payment gateways with controllers.
|
||||||
|
- **Consequences**: Harder to manage, test, and replace payment services.
|
||||||
|
|
||||||
|
## Consequences
|
||||||
|
Implementing the payment boundary allows for better maintainability, easier testing, and the ability to swap out payment services if necessary without significant changes to the rest of the application.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue