Clean Architecture Validator Skill

Use this skill to validate that a .NET API project follows StyleMate's Clean Architecture standards with proper layer separation and dependencies.

When to Use

• After creating a new .NET API project
• When refactoring an existing API
• During code reviews
• Troubleshooting dependency issues
• Ensuring architectural compliance

What This Skill Does

1. Structure Validation

Checks for required directories:

• Domain/ (no dependencies)
• Application/ (depends on Domain only)
• Infrastructure/ (implements interfaces)
• Controllers/ (orchestration layer)

2. Dependency Analysis

Validates that:

• Domain has NO dependencies on other layers
• Application depends only on Domain
• Infrastructure implements Domain/Application interfaces
• Controllers depend on all layers for orchestration
• No circular dependencies exist

3. Entity Validation

Ensures Domain entities:

• Contain business logic
• Have proper value objects
• Define domain interfaces
• Use proper encapsulation

4. Service Layer Check

Validates Application services:

• Define clear DTOs
• Implement business workflows
• Use dependency injection properly
• Return appropriate types (not entities)

5. Infrastructure Compliance

Checks Infrastructure layer:

• Proper DbContext configuration
• Repository pattern implementation
• External service integrations
• Configuration management

Expected Inputs

• Path to the .NET API project
• Context name for the service

Deliverables

• Validation report with pass/fail status
• List of violations with recommendations
• Suggested refactoring steps (if needed)
• Compliance checklist

Example Usage

Please validate the staff-api project structure to ensure it follows Clean Architecture.
The project is located at ./staff/staff-api/

Validation Checklist

Domain Layer ✓

• Entities/ directory exists with domain models
• Interfaces/ directory for domain contracts
• No dependencies on other layers
• Business logic in entities
• Value objects properly defined

Application Layer ✓

• DTOs/ directory for data transfer
• Services/ directory for business workflows
• Interfaces/ for service contracts
• Only depends on Domain layer
• No infrastructure concerns

Infrastructure Layer ✓

• Data/ directory with DbContext
• Repositories/ implementing domain interfaces
• Services/ for external integrations
• Implements Application/Domain interfaces
• EF Core configurations present

API Layer (Controllers) ✓

• Controllers orchestrate workflow
• Proper routing with [Route] attributes
• JWT authorization on endpoints
• Input validation with FluentValidation
• Returns DTOs, not entities

Configuration ✓

• Program.cs properly configures DI
• appsettings.json has required sections
• Middleware pipeline configured
• Health checks implemented
• Swagger with JWT scheme

Common Violations

❌ Domain depending on Infrastructure

// WRONG: Domain referencing DbContext
using Infrastructure.Data;

public class Employee
{
    public void Save(AppDbContext context) { } // ❌
}

✓ Correct Domain

// CORRECT: Domain with no dependencies
public class Employee
{
    public Guid Id { get; private set; }
    public string Name { get; private set; }

    // Business logic only
    public void UpdateName(string newName)
    {
        if (string.IsNullOrWhiteSpace(newName))
            throw new ArgumentException("Name required");
        Name = newName;
    }
}

❌ Returning Entities from Controllers

// WRONG: Exposing domain entities
[HttpGet]
public async Task<Employee> Get(Guid id) // ❌
{
    return await _service.GetEmployee(id);
}

✓ Correct Controller Pattern

// CORRECT: Returning DTOs
[HttpGet]
public async Task<EmployeeDto> Get(Guid id) // ✓
{
    return await _service.GetEmployee(id);
}

Remediation Steps

When violations found:

1. Identify the violating layer
2. Move code to appropriate layer
3. Define interfaces where needed
4. Update dependency injection
5. Revalidate structure