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