🏗️ Subscription Tracker API Architecture

Layered architecture with dependency inversion principle

🌐 PRESENTATION LAYER (Presentation Layer) High Level
🎯 HTTP Handlers
📝 Request/Response Models
✅ Validation
🔒 CORS Middleware
📊 Swagger Documentation
handlers.NewSubscriptionHandler(service SubscriptionServiceInterface, logger)

Responsibility: HTTP requests/responses, input data validation, status codes

Depends on: SubscriptionServiceInterface

⬇️
🧠 BUSINESS LAYER (Business Logic) Middle Level
⚡ Subscription Service
🔄 Transaction Execution
📋 Business Rules
💰 Cost Calculation
🛡️ Data Validation
service.NewSubscriptionService(repo SubscriptionRepositoryInterface, logger)

Responsibility: Business rules, data validation, transaction execution

Depends on: SubscriptionRepositoryInterface

⬇️
🗄️ DATA LAYER (Data Layer) Low Level
📦 Subscription Repository
🔍 CRUD Operations
📈 Query Optimization
repository.NewSubscriptionRepository(db *gorm.DB, logger)

Responsibility: Database operations, working with GORM

Depends on: *gorm.DB (concrete implementation)

⬇️
🔌 EXTERNAL LAYER (External Services) Infrastructure
🐘 PostgreSQL Database
📝 Logrus Logger
🔄 Transaction Management
⚙️ Configuration
🔄 Database Migrations

Responsibility: External dependencies, database, file system, network

🔄 Dependency Inversion Principle in Action

Handler
(high level)
ServiceInterface
(abstraction)
Service
(middle level)
RepositoryInterface
(abstraction)
Repository
(low level)

✅ What we get:

  • 🧪 Testability: We can easily mock dependencies
  • 🔧 Flexibility: We can change implementations without code changes
  • 🔗 Loose coupling: Layers don't know about concrete implementations
  • 📦 Modularity: Each layer has clear responsibility

🔄 Request Execution Flow

1. Handler
Receives HTTP request
→
2. Service
Executes business logic
→
3. Repository
Works with database
→
4. Database
Returns data

Each layer only knows about its immediate dependencies through interfaces