---

name: dry-violations description: Use when implementing new features, adding constants, creating types, or writing business logic. Use when you're about to hardcode values that might exist elsewhere. Use when auditing code for duplications in enums, constants, domain methods, or type definitions.

DRY Violation Detection

Overview

Search BEFORE you implement. Every hardcoded value is a potential duplication.

DRY (Don't Repeat Yourself) violations aren't just about copy-pasted code. They include:

• Hardcoded arrays that duplicate existing enums
• Type definitions that duplicate existing domain types
• Constants defined in multiple places
• Business logic that duplicates domain methods
• String literals that should reference enums

When to Use

Copydigraph dry_check {
    "About to hardcode a value?" [shape=diamond];
    "Creating array/constant?" [shape=diamond];
    "Writing business logic?" [shape=diamond];
    "SEARCH first" [shape=box, style=filled];
    "Proceed" [shape=box];

    "About to hardcode a value?" -> "SEARCH first" [label="yes"];
    "About to hardcode a value?" -> "Creating array/constant?" [label="no"];
    "Creating array/constant?" -> "SEARCH first" [label="yes"];
    "Creating array/constant?" -> "Writing business logic?" [label="no"];
    "Writing business logic?" -> "SEARCH first" [label="yes"];
    "Writing business logic?" -> "Proceed" [label="no"];
}

Trigger symptoms:

• "I'll just hardcode these values quickly"
• "I need a list of [X] types"
• "Let me define these constants"
• Creating a new enum/type
• Writing a calculation or detection method

The Search-First Protocol

Before implementing ANY of these, SEARCH the codebase:

Search Commands

Copy# Find enums
grep -r "export enum" src/

# Find type/constant by concept name (example: payment types)
grep -ri "payment.*type\|PaymentType" src/

# Find domain methods
grep -r "isEligible\|calculate\|validate" src/

# Find all type definitions
grep -r "export type\|export interface" src/

Common DRY Violation Patterns

1. Hardcoded Array vs Existing Enum

Copy// ❌ DRY VIOLATION: Hardcoded array
const ORDER_STATUSES = ['pending', 'confirmed', 'shipped', 'delivered'];

// ✅ CORRECT: Reference existing enum
import { OrderStatus } from './domain/order-status.enum';
const statuses = Object.values(OrderStatus);

2. Local Constant vs Shared Definition

Copy// ❌ DRY VIOLATION: Local constant duplicating domain knowledge
const PREMIUM_TIERS = [UserTier.Gold, UserTier.Platinum, UserTier.Diamond];

// ✅ CORRECT: Use existing domain method or shared constant
const isPremium = user.isPremiumTier();
// Or use shared constant:
import { PREMIUM_TIERS } from './domain/user-tier-groups';

3. New Type vs Existing Domain Type

Copy// ❌ DRY VIOLATION: Creating duplicate type
interface ProductCategory {
  name: string;
  products: string[];
}

// ✅ CORRECT: Import existing definition
import { ProductCategory } from './domain/product-category';

4. Service Logic vs Domain Method

Copy// ❌ DRY VIOLATION: Logic that belongs in domain
class DiscountCalculationService {
  isEligibleForDiscount(orders: Order[]): boolean {
    return orders.filter(o => o.status === 'completed').length >= 5;
  }
}

// ✅ CORRECT: Domain method already exists (or should)
const isEligible = customer.isEligibleForDiscount();

5. String Literals vs Enum Values

Copy// ❌ DRY VIOLATION: String literal
if (payment.method === 'credit_card') { ... }

// ✅ CORRECT: Use enum
if (payment.method === PaymentMethod.CreditCard) { ... }

6. Duplicate Validation Logic

Copy// ❌ DRY VIOLATION: Validation duplicated in controller and service
// In controller:
if (!email.includes('@')) throw new BadRequest('Invalid email');
// In service:
if (!email.includes('@')) throw new Error('Invalid email');

// ✅ CORRECT: Centralized validation
import { validateEmail } from './domain/validators';
validateEmail(email); // Throws if invalid

Quick Reference: Where to Search

Red Flags - STOP and Search

Audit Checklist

When reviewing code for DRY violations:

• Are there hardcoded arrays that duplicate enums?
• Are there local constants that duplicate shared definitions?
• Are there type definitions that duplicate domain types?
• Are there service methods that duplicate domain logic?
• Are there string literals that should reference enums?
• Are the same values defined in multiple places?
• Is validation logic duplicated across layers?
• Are error messages defined inline instead of using constants?

Impact of DRY Violations

Conceptual Groupings: Centralize or Inline?

Even when using proper enum references, creating groupings can be a DRY violation.

Ask: Is this grouping a domain concept or a one-off filter?

Copy// ❌ POTENTIAL DRY VIOLATION: Domain concept scattered
// In service A:
const refundableStatuses = [OrderStatus.Pending, OrderStatus.Confirmed];
// In service B:
const refundableStatuses = [OrderStatus.Pending, OrderStatus.Confirmed];

// ✅ CORRECT: Centralize domain concept
// In domain/order-status-groups.ts:
export const REFUNDABLE_STATUSES = [
  OrderStatus.Pending,
  OrderStatus.Confirmed
] as const;

// Usage everywhere:
import { REFUNDABLE_STATUSES } from './domain/order-status-groups';

Search before creating any grouping:

Copygrep -ri "pending.*confirmed\|refundable" src/

Domain Methods vs Service Methods

When you need logic that operates on domain data, ask:

Copy// ❌ Service with logic that belongs in domain
class OrderService {
  canBeCancelled(order: Order): boolean {
    return ['pending', 'confirmed'].includes(order.status) &&
           order.createdAt > Date.now() - 24 * 60 * 60 * 1000;
  }
}

// ✅ Domain method
class Order {
  canBeCancelled(): boolean {
    return this.isInCancellableStatus() && this.isWithinCancellationWindow();
  }

  private isInCancellableStatus(): boolean {
    return CANCELLABLE_STATUSES.includes(this.status);
  }

  private isWithinCancellationWindow(): boolean {
    return this.createdAt > Date.now() - CANCELLATION_WINDOW_MS;
  }
}

Common Rationalizations

Prevention Strategies

1. Establish Canonical Locations

Document where different types of definitions live:

Copysrc/
├── shared/
│   ├── constants/      # App-wide constants
│   ├── enums/          # Shared enums
│   └── types/          # Shared type definitions
├── [module]/
│   └── domain/
│       ├── *.enum.ts   # Module-specific enums
│       ├── *.ts        # Domain entities with methods
│       └── groups/     # Conceptual groupings

2. Naming Conventions

Consistent naming makes searching easier:

3. Code Review Questions

• "Does this constant/type already exist?"
• "Could this logic be a domain method?"
• "Is this grouping used elsewhere?"
• "Did you search before implementing?"