✅ Correct: A class/function does only one thing
- UserService: User business logic
- UserRepository: User data access
- UserValidator: User data validation

❌ Incorrect: A class does multiple things
- UserManager: Business logic + data access + validation + email sending

┌─────────────────────────────────────┐
│           Interface Layer           │  ← Thin layer, no business logic
├─────────────────────────────────────┤
│           Service Layer             │  ← Business logic (core)
├─────────────────────────────────────┤
│           Domain Layer              │  ← Domain model
├─────────────────────────────────────┤
│         Infrastructure Layer        │  ← Replaceable
└─────────────────────────────────────┘

Dependency Rules:
- Outer layers depend on inner layers ✅
- Inner layers depend on outer layers ❌
- Depend on interfaces, not implementations ✅

// ❌ Too many parameters
function createUser(name, email, age, role, department, manager) {}

// ✅ Use parameter object
function createUser(params: CreateUserParams) {}

// ❌ Excessive nesting
if (a) {
  if (b) {
    if (c) {
      // ...
    }
  }
}

// ✅ Early return
if (!a) return;
if (!b) return;
if (!c) return;
// ...

Three elements of testable code:
1. Injectable dependencies - External dependencies are passed via parameters
2. Prefer pure functions - Business logic has no side effects
3. Boundary separation - Separate business logic from IO operations

// ❌ Hard-coded dependencies
class UserService {
  private db = new Database();
  private mailer = new EmailService();
}

// ✅ Dependency injection
class UserService {
  constructor(
    private db: IDatabase,
    private mailer: IEmailService
  ) {}
}

// ❌ Has side effects, hard to test
function calculateTotal(items) {
  const total = items.reduce((sum, item) => sum + item.price, 0);
  console.log(`Total: ${total}`);  // Side effect
  analytics.track('calculate');     // Side effect
  return total;
}

// ✅ Pure function, easy to test
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

// ❌ Business logic mixed with IO
async function processOrder(orderId) {
  const order = await db.findOrder(orderId);  // IO
  if (order.total > 1000) {                   // Business logic
    order.discount = 0.1;
  }
  await db.save(order);                       // IO
  await email.send(order.user, 'confirmed');  // IO
}

// ✅ Separate business logic
function applyDiscount(order) {  // Pure business logic, testable
  if (order.total > 1000) {
    return { ...order, discount: 0.1 };
  }
  return order;
}

async function processOrder(orderId) {
  const order = await db.findOrder(orderId);
  const updated = applyDiscount(order);  // Call pure function
  await db.save(updated);
  await email.send(order.user, 'confirmed');
}

// ❌ Over-engineering: Adding configurations for hypothetical requirements
const config = {
  maxRetries: 3,
  retryDelay: 1000,
  enableCache: true,
  cacheExpiry: 3600,
  enableRateLimit: false,  // Never used
  rateLimitWindow: 60000,  // Never used
  enableMetrics: false,    // Never used
  metricsEndpoint: '',     // Never used
};

// ✅ Only add configurations needed currently
const config = {
  maxRetries: 3,
  retryDelay: 1000,
  cacheExpiry: 3600,
};

❌ Premature abstraction:
- Create an interface when there's only one implementation
- Extract a function when it's only used once
- Create a base class when there are only two similar scenarios

✅ Timely abstraction (Rule of Three):
- Consider interfaces when there are 3+ implementations
- Consider extraction when there are 3+ repetitions
- Consider base classes when there are 3+ similar scenarios

// ❌ Over-engineering: Using complex patterns for simple scenarios
class UserFactory {
  createAdmin() { return new AdminUser(); }
  createMember() { return new MemberUser(); }
  createGuest() { return new GuestUser(); }
}

// ✅ Use simple solutions for simple scenarios
function createUser(role: 'admin' | 'member' | 'guest') {
  return { role, permissions: getPermissions(role) };
}

1. Ensure test coverage
   │
   ├── Has tests → Proceed
   └── No tests → Add tests first
   │
   ▼
2. Small-step refactoring
   │
   ├── Only change one thing at a time
   ├── Ensure code runs after each step
   └── Run tests after each step
   │
   ▼
3. Verify unchanged behavior
   │
   ├── All tests pass
   └── Manually verify critical paths
   │
   ▼
4. Commit code