Compare commits
2 commits
main
...
forge/SPRI
| Author | SHA1 | Date | |
|---|---|---|---|
| 6a28a1ffe2 | |||
| 88b0bcf8b4 |
2 changed files with 18 additions and 0 deletions
|
|
@ -0,0 +1,3 @@
|
||||||
|
# SPRING-ARC-RUN-1783834407-attempt-1-run-d553410e34bd
|
||||||
|
|
||||||
|
Forge 이슈 작업 브랜치 `forge/SPRING-ARC-RUN-1783834407-attempt-1-run-d553410e34bd`.
|
||||||
15
docs/architecture/adr-payment-boundary.md
Normal file
15
docs/architecture/adr-payment-boundary.md
Normal file
|
|
@ -0,0 +1,15 @@
|
||||||
|
# Context
|
||||||
|
|
||||||
|
The payment processing architecture defines how various components interact to facilitate payment transactions. Establishing boundaries is critical to ensure that the integration of payment gateways is seamless and maintains the integrity of domain logic.
|
||||||
|
|
||||||
|
# Decision
|
||||||
|
|
||||||
|
To implement a clean architecture where the domain layer is isolated from the external payment gateway. Payment gateways will be accessed indirectly through a defined port (interface) in the infrastructure layer, allowing for easy replacements and modifications in the future.
|
||||||
|
|
||||||
|
# Alternatives
|
||||||
|
1. **Tightly Coupling the Domain with Payment Gateways**: This approach allows for direct interaction but will hinder the flexibility and testability of the domain logic.
|
||||||
|
2. **Utilizing an Orchestrator Service**: An additional layer that coordinates between the domain and the payment service, which may introduce unnecessary complexity.
|
||||||
|
|
||||||
|
# Consequences
|
||||||
|
- **Pros**: Increased testability and maintainability of the domain layer, reduced complexity in domain logic, and easier replacement of payment gateways.
|
||||||
|
- **Cons**: Slightly increased complexity in terms of setting up the interface and adapters, potential initial overhead in development.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue