Skip to content
Development
Command

/audit-layer-boundaries

Analyze layer boundary definitions in Rust codebases, identifying mixed responsibilities and violations

From plugin
claude-command-suite
1.3k199 skills89 agents199 commands
Install
$ npx -y skills add qdhenry/Claude-Command-Suite --agent claude-code

How it fires

How this command gets triggered: by you, by Claude, or both.

  • Fires itselfClaude auto-loads it when your prompt matches the work.
  • You can call itInvoke it directly when you want it.
  • Slash command/audit-layer-boundaries

Context preview

What this command does when you run it.

Analyze layer boundary definitions in Rust codebases, identifying mixed responsibilities and violations

Command definition

audit-layer-boundaries.md
name: rust:audit-layer-boundaries
description: Analyze layer boundary definitions in Rust codebases, identifying mixed responsibilities and violations
allowed-tools: Read, Grep, Glob, Bash
author: Quintin Henry (https://github.com/qdhenry/)

Audit Layer Boundaries

Analyze how well-defined the architectural layer boundaries are in a Rust codebase, identifying mixed responsibilities, unclear separation, and boundary violations.

Instructions

Audit layer boundaries in the codebase: **$ARGUMENTS**

> **Note:** `$ARGUMENTS` can specify a path or focus area. > Examples: > - `/rust:audit-layer-boundaries` - Full boundary audit > - `/rust:audit-layer-boundaries src/core/` - Focus on specific path

---

Layer Responsibility Reference

| Layer | Responsibility | Should NOT Contain | |-------|---------------|-------------------| | **Domain** | Entities, value objects, domain services, business rules | Serialization, HTTP, DB queries, config | | **Application** | Use cases, orchestration, port definitions, app errors | HTTP handlers, DB implementations, framework types | | **Adapters** | HTTP handlers, DB repositories, external API clients, serialization | Business logic, configuration setup | | **Infrastructure** | App startup, config loading, DB pools, dependency wiring | Business logic, HTTP handling |

---

Phase 1: Identify Layer Structure

1.1 Discover Project Organization

# List top-level source structure
ls -la src/

# Find all modules
find src -name "mod.rs" -o -name "lib.rs" | head -20

# Check for layer-like directories
for pattern in domain application adapters infrastructure core lib api handlers services controllers repositories; do
  found=$(find src -type d -name "$pattern" 2>/dev/null)
  [ -n "$found" ] && echo "Layer candidate: $found"
done

1.2 Document Layer Mapping

## Current Layer Structure

| Identified Directory | Mapped Layer | Confidence |
|---------------------|--------------|------------|
| `src/???` | Domain | High/Medium/Low |
| `src/???` | Application | High/Medium/Low |
| `src/???` | Adapters | High/Medium/Low |
| `src/???` | Infrastructure | High/Medium/Low |
| `src/???` | UNCLEAR | - |

---

Phase 2: Domain Layer Boundary Audit

2.1 Domain Purity Check

The domain should contain ONLY business logic.

# Find all files in domain layer
find src/domain -name "*.rs" 2>/dev/null

# Check each file for boundary violations
for file in $(find src/domain -name "*.rs" 2>/dev/null); do
  echo "=== $file ==="

  # Check for HTTP concerns
  grep -n "HttpResponse\|StatusCode\|axum::\|actix::\|Request\|Response" "$file"

  # Check for DB concerns
  grep -n "sqlx::\|diesel::\|query!\|execute\|Pool\|Connection" "$file"

  # Check for serialization in struct definitions
  grep -n "Serialize\|Deserialize\|Json<" "$file"
done

2.2 Domain Should Contain

// GOOD: Domain content
pub struct User { ... }              // Entities
pub struct Email(String);            // Value objects
pub fn validate_email(s: &str) -> bool { ... }  // Domain rules
pub trait DomainService { ... }      // Domain services
pub enum DomainError { ... }         // Domain errors

2.3 Domain Should NOT Contain

// BAD: HTTP in domain
#[derive(Deserialize)]               // Serialization concern
pub struct CreateUserRequest { ... }

// BAD: DB in domain
#[derive(sqlx::FromRow)]             // Persistence concern
pub struct User { ... }

// BAD: Framework types in domain
pub fn handler(req: HttpRequest) { ... }

---

Phase 3: Application Layer Boundary Audit

3.1 Application Layer Content Check

# Find application layer files
find src/application -name "*.rs" 2>/dev/null

# Check for misplaced responsibilities
for file in $(find src/application -name "*.rs" 2>/dev/null); do
  echo "=== $file ==="

  # HTTP concerns (should be in adapters)
  grep -n "HttpResponse\|StatusCode\|Json<\|Path<\|Query<" "$file"

  # Direct DB queries (should use repository trait)
  grep -n "sqlx::query\|diesel::\|\.execute(\|\.fetch" "$file"

  # Framework routing
  grep -n "Router\|route\|get\|post\|put\|delete" "$file"
done

3.2 Application Should Contain

// GOOD: Application content
pub struct RegisterUser { ... }      // Use cases
pub trait UserRepository { ... }     // Port traits
pub enum AppError { ... }            // Application errors
pub async fn execute(&self) { ... }  // Use case execution

3.3 Application Should NOT Contain

// BAD: HTTP handlers in application
pub async fn register_handler(Json(body): Json<...>) -> impl IntoResponse { ... }

// BAD: Direct DB access
let user = sqlx::query!("SELECT * FROM users").fetch_one(&pool).await?;

// BAD: Concrete adapter types
pub struct RegisterUser {
    db: PgPool,  // Should be trait object
}

---

Phase 4: Adapters Layer Boundary Audit

4.1 Adapter Content Check

# Find adapter layer files
find src/adapters -name "*.rs" 2>/dev/null

# Check for business logic leakage
for file in $(find src/adapters -name "*.rs" 2>/dev/null); do
  echo "=== $file ==="

  # Complex business logic (should be in application/domain)
  grep -n "if.*&&.*&&\|match.*=>" "$file" | head -5

  # Business validation (should be in domain)
  grep -n "validate\|is_valid\|check_" "$file"
done

4.2 Adapters Should Contain

// GOOD: Adapter content
impl UserRepository for PostgresUserRepository { ... }  // Port implementations
pub async fn register_handler(...) -> impl IntoResponse { ... }  // HTTP handlers
pub fn app_error_to_response(e: AppError) -> Response { ... }  // Error conversion
pub struct CreateUserDto { ... }     // DTOs with serialization

4.3 Adapters Should NOT Contain

// BAD: Business logic in adapter
pub async fn register_handler(...) {
    // Business rules should be in use case
    if password.len() < 8 { return Err(...) }
    if !email.contains('@') { return Err(...) }
    // ...
}

// BAD: Mu
Read more
Ships withclaude-command-suite

A comprehensive development toolkit designed following Anthropic's Claude Code Best Practices for AI-assisted software development.

Get the whole plugin