What is clean-architecture-review?

This Claude skill automates the validation of Clean Architecture and MVVM patterns in iOS development. It systematically checks for strict layer separation between Presentation, Domain, and Data layers, verifies dependency injection via Swinject, and ensures proper implementation of UseCase and Repository patterns to maintain a scalable, maintainable, and testable codebase.

When should I use clean-architecture-review?

clean-architecture-review is useful in the following scenarios: • Automated Architecture Audits: Conduct comprehensive reviews of iOS modules to ensure strict adherence to Clean Architecture boundaries and identify structural violations. • Pull Request Quality Gates: Use the skill during code reviews to automatically detect critical issues like business logic leaks in ViewModels or direct API calls bypassing the Domain layer. • Legacy Code Refactoring: Analyze existing iOS codebases to generate detailed compliance reports, dependency graphs, and prioritized refactoring steps for modernization. • Dependency Injection Validation: Verify the correct usage of Swinject for constructor injection and ensure all components are properly decoupled through protocol-oriented programming. • Developer Onboarding: Provide immediate, actionable feedback to team members on implementing standardized patterns like BaseViewModel and UseCase/Repository protocols.

name	clean-architecture-review
description	Validate Clean Architecture implementation in iOS. Checks layer separation (Presentation/Domain/Data), MVVM patterns, dependency injection with Swinject, and UseCase/Repository patterns. Use when reviewing architecture, checking layer boundaries, or validating DI.
allowed-tools	Read, Grep, Glob

Clean Architecture Validator

Verify Clean Architecture and MVVM implementation in iOS code following Payoo Merchant patterns.

When to Activate

"architecture review", "layer separation", "clean architecture"
"MVVM", "dependency injection", "DI"
"use case", "repository pattern"
Reviewing module structure or refactoring

Architecture Layers

Presentation → ViewControllers, ViewModels, Views Domain → UseCases (business logic), Models, Repository protocols Data → Repository implementations, API Services, Local Storage

Correct Flow:

UI → ViewController → ViewModel → UseCase → Repository → API/DB

Review Process

Step 1: Map Architecture

Classify files into layers:

Presentation: *ViewController.swift, *ViewModel.swift
Domain: *UseCase.swift, *Repository.swift (protocols)
Data: *RepositoryImpl.swift, *ApiService.swift

Step 2: Check Layer Violations

Critical Issues:

🔴 ViewModel calling API directly (bypassing UseCase)
🔴 Business logic in ViewModel (should be in UseCase)
🔴 UseCase calling API directly (bypassing Repository)
🔴 Direct instantiation (no DI)

Step 3: Verify Patterns

BaseViewModel:

✅ class PaymentViewModel: BaseViewModel<PaymentState>
❌ class PaymentViewModel  // Should extend BaseViewModel

UseCase Pattern:

✅ protocol PaymentUseCase { }
✅ class PaymentUseCaseImpl: PaymentUseCase { }
❌ class PaymentUseCase { }  // Should be protocol + impl

Repository Pattern:

✅ protocol PaymentRepository { }  // In Domain
✅ class PaymentRepositoryImpl: PaymentRepository { }  // In Data

Dependency Injection:

✅ init(paymentUC: PaymentUseCase) {  // Constructor injection
    self.paymentUC = paymentUC
}
❌ let paymentUC = PaymentUseCaseImpl()  // Direct instantiation

Step 4: Generate Report

Provide:

Architecture compliance score
Layer violations by severity
Current vs. should-be architecture
Refactoring steps
Effort estimate

Common Violations

❌ ViewModel Bypassing UseCase

class PaymentViewModel {
    private let apiService: PaymentApiService  // WRONG LAYER!
}

Should be:

class PaymentViewModel {
    private let paymentUC: PaymentUseCase  // CORRECT!
}

❌ Business Logic in ViewModel

class PaymentViewModel {
    func processPayment(amount: Double) {
        // ❌ Validation in ViewModel
        guard amount > 1000 else { return }
        // ❌ Business rules in ViewModel
        let fee = amount * 0.01
    }
}

Should be in UseCase:

class PaymentUseCaseImpl {
    func execute(amount: Double) -> Single<PaymentResult> {
        // ✅ Validation in UseCase
        return validateAmount(amount)
            .flatMap { processPayment($0) }
    }
}

Output Format

# Clean Architecture Review

## Compliance Score: X/100

## Critical Violations: X

### 1. ViewModel Bypassing UseCase
**File**: `PaymentViewModel.swift:15`
**Current**: ViewModel → API
**Should be**: ViewModel → UseCase → Repository → API

**Fix**: [Refactoring steps]

---

## Dependency Graph

### Current (Problematic)
ViewModel → ApiService ❌

### Should Be
ViewModel → UseCase → Repository → ApiService ✅

## Recommendations
1. Create missing UseCases
2. Move business logic to Domain layer
3. Setup DI container
4. Add Repository layer

## Effort Estimate
- Module refactoring: X hours
- DI setup: X hours
- Testing: X hours

Quick Checks

Layer Boundaries:

ViewModels only depend on UseCases
UseCases contain all business logic
Repositories handle data access only
No UI code in Domain/Data layers