SKILL.md

--- frontmatter

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:

code

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:

swift

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

UseCase Pattern:

swift

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

Repository Pattern:

swift

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

Dependency Injection:

swift

✅ 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

swift

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

Should be:

swift

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

❌ Business Logic in ViewModel

swift

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:

swift

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

Output Format

markdown

# 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

Dependency Injection:

• All dependencies via constructor
• No direct instantiation
• Swinject container registration
• Protocol-based dependencies

Patterns:

• ViewModels extend BaseViewModel
• UseCases follow protocol + impl
• Repositories follow protocol + impl
• State management via setState()

Reference

Detailed Examples: See examples.md for complete architecture patterns and refactoring guides.