Compare commits
2 commits
main
...
forge/SPRI
| Author | SHA1 | Date | |
|---|---|---|---|
| 00c6800ea3 | |||
| f0aa1bad7e |
2 changed files with 18 additions and 0 deletions
3
.forge/SPRING-ARC-VERIFIED-1783826844-attempt-3.md
Normal file
3
.forge/SPRING-ARC-VERIFIED-1783826844-attempt-3.md
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
# SPRING-ARC-VERIFIED-1783826844-attempt-3
|
||||||
|
|
||||||
|
Forge 이슈 작업 브랜치 `forge/SPRING-ARC-VERIFIED-1783826844-attempt-3`.
|
||||||
15
docs/architecture/adr-payment-boundary.md
Normal file
15
docs/architecture/adr-payment-boundary.md
Normal file
|
|
@ -0,0 +1,15 @@
|
||||||
|
# Payment Boundary Decision Record
|
||||||
|
|
||||||
|
## Context
|
||||||
|
In developing the architecture for the payment processing system, our objective is to ensure a clear separation between the application logic and the payment gateways. This boundary will help maintain a clean architecture and allow for easier testing and maintainability.
|
||||||
|
|
||||||
|
## Decision
|
||||||
|
We have decided to implement a port and adapter pattern where the payment gateway is accessed via a defined interface (port) rather than being directly referenced in the domain model. This ensures that our domain logic remains agnostic of the specific implementations of payment gateways.
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
1. Direct coupling with the payment gateway: This approach could lead to tight coupling and hinder maintainability and testability.
|
||||||
|
2. Abstracting payment logic into a service layer: While this maintains separation, it increases complexity and could introduce overhead.
|
||||||
|
|
||||||
|
## Consequences
|
||||||
|
- By adhering to the port and adapter pattern, we ensure our domain model remains clean and focused on business logic.
|
||||||
|
- Changes in payment gateway implementations can be managed without affecting the domain logic, leading to improved agility.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue