Communication patterns
API to domain layer
The API layer delegates business logic to the domain layer through managers:- Controllers are thin, delegating to managers
- Managers orchestrate business logic
- DTOs used for request/response
- Async/await for all I/O operations
Domain to data layer
The domain layer accesses data through stores (repository pattern):- Stores encapsulate data access logic
- Entity Framework Core for ORM
- Stored procedures for complex queries
- Transactions for data consistency
Admin UI to API
The Admin UI communicates with the API through typed HTTP clients:- Typed clients for type safety
- OAuth2 authentication
- Retry policies for resilience
- Response caching where appropriate
Payment processor integration
The domain layer integrates with payment processors through service interfaces:- Factory pattern for processor selection
- Standardized request/response models
- Error handling and retry logic
- Logging of all interactions
Component interaction flows
Transaction processing flow
- Client sends transaction request to API
- API validates request and delegates to domain manager
- Domain manager creates transaction record in database
- Domain manager calls payment processor service
- Processor service sends request to external processor
- Processor returns response
- Domain manager updates transaction with result
- API returns response to client
Account updater flow
- Background process triggers account updater
- Domain service queries cards to update from database
- Domain service generates CSV file
- File uploaded to S3
- Domain service uploads file to CyberSource
- CyberSource processes batch (24-48 hours)
- Background process downloads results
- Domain service parses results and updates database
Chargeback processing flow
- Background process triggers chargeback download
- Domain service downloads chargeback report from CyberSource
- Domain service parses CSV report
- Domain service matches chargebacks to transactions
- Domain service creates reversal transactions
- Domain service sends email notifications
- Admin UI displays chargeback alerts
Inter-service communication
HTTP clients
The platform uses typed HTTP clients for service-to-service communication: Admin clients (Chargeworx.Api.AdminClients)- Company management
- Project management
- User management
- Transaction management
- Report generation
- Transaction processing
- Payment info management
- Charge event processing
SignalR for real-time updates
The Admin UI uses SignalR for real-time notifications:- Background process status updates
- Transaction alerts
- System notifications
- User activity monitoring
Background processing
Background processes coordinate through a queue-based system:- Account updater batch processing
- Chargeback report downloads
- Transaction report synchronization
- Data import processing
Database interactions
Multi-database coordination
The platform uses four separate databases with coordinated transactions:Stored procedures
Complex queries use stored procedures for performance:Bulk operations
Import operations use bulk inserts for performance:External service integration
CyberSource integration
SOAP API (legacy transactions):PayPal Payflow integration
AWS services
S3 for file storage:Error handling and resilience
Retry policies
HTTP clients use Polly for retry logic:Circuit breaker
Prevent cascading failures with circuit breaker:Exception handling
Centralized exception handling in middleware:Caching strategy
Response caching
API endpoints use response caching:Distributed caching
Session state and frequently accessed data use distributed cache:Security considerations
Authentication flow
- Client requests token from IdentityServer
- IdentityServer validates credentials
- IdentityServer returns access token
- Client includes token in API requests
- API validates token and processes request
