22 lines
No EOL
1.5 KiB
Markdown
22 lines
No EOL
1.5 KiB
Markdown
# ADR: Payment Boundary
|
|
|
|
## Context
|
|
In order to integrate a payment gateway effectively, we need to ensure a clear boundary between the domain logic and external payment processes. This boundary helps maintain system integrity and promotes loose coupling, facilitating easier updates and replacements of payment systems in the future.
|
|
|
|
## Decision
|
|
We will implement an adapter pattern for the payment integration. The payment gateway will be accessed through a port interface from the domain services, ensuring the domain does not directly reference the gateway implementation.
|
|
The key points are:
|
|
- Use of port interfaces to access payment services.
|
|
- Define specific adapters for each payment gateway.
|
|
- Ensure that the domain logic is independent of external payment systems.
|
|
|
|
## Alternatives
|
|
- **Direct Integration:** Directly calling payment gateway APIs from domain services.
|
|
- **Consequences:** Tight coupling between domain and payment systems, leading to harder maintenance and updates.
|
|
- **Service Layer Approach:** Introduce a service layer without adapters.
|
|
- **Consequences:** This could increase complexity without achieving the decoupling we desire, as the service layer would still need to know about the payment gateway details.
|
|
|
|
## Consequences
|
|
By implementing the proposed decision:
|
|
- We achieve a clear separation of concerns, improving maintainability.
|
|
- The domain layer remains clean and focused on its core business logic without knowledge of payment gateway specifics. |