Less Greedy Code, Less Misery: The Power of SRP Through a Battle-Tested Lens

Source: Manul X
Published: 2026-05-24T15:13:44.206Z
Modified: 2026-05-28T00:41:23.787Z
Language: en
Author: Manul X Editorial
Category: Software Engineering
Tags: solid

Throughout my years of working across all kinds of projects—from classic monolithic systems and complex microservices to mobile apps—I've come to realize a bitter truth: The vast majority of critical bugs on Production don't stem from poor algorithms; they come from cramming too many responsibilities into one place.

We often fall into a psychological trap called "convenience."

"Since I'm already in this logic handler, let me just add a few lines of logging, and maybe trigger an event to a third-party service real quick while I'm at it."

The result? The system runs flawlessly for the first two weeks. By the third month, as the business scales and change requests come pouring in, that "convenient" code morphs into a Frankenstein's Monster (a God Object). Fixing a bug here breaks a feature there, and no one on the team dares to touch it for fear of a domino effect.

Today, let's dissect the most fundamental principle—the very line that separates a person who merely "writes working code" from a true Software Engineer: the Single Responsibility Principle (SRP).

1. SRP Through a Pragmatic Lens: Forget the Textbook Definition

If you look up SRP online, textbooks will tell you: "A class or module should have only one reason to change."

That sounds highly academic. But when building large-scale systems, I define it more pragmatically: "A function or class should be responsible for exactly one business boundary (Context/Boundary) and serve only one specific actor."

Think of a system as a restaurant:

• The Chef (Developer writing core logic) only focuses on cooking delicious food, fast.
• The Cashier (Database/Accounting) only focuses on processing payments accurately.

If the chef tries to stir-fry noodles, rush out to swipe a customer's credit card, and "conveniently" grabs a broom to sweep the floor all at the same time—the system will inevitably crash when rush hour hits (High Load). The noodles burn, payments get messed up, and customers walk out.

Code behaves exactly the same way.

2. The Blueprint of a "Future Legacy Code"

Let's look directly at a typical order processing function that I bet you've encountered at least three times in your career.

TypeScript

// WARNING: This is a one-way ticket to sleepless on-call nights!
async function processOrder(order: any) {
  // 1. Business Logic Validation
  if (!order.items || order.items.length === 0) {
    throw new Error("Invalid order items");
  }

  // 2. Pricing & Tax Calculation (Core Logic)
  let total = 0;
  for (const item of order.items) {
    total += item.price * item.quantity;
  }
  if (order.vipCode) {
    total = total * 0.85; // 15% discount for VIPs
  }

  // 3. Data Persistence (Database Interaction)
  const db = await getDatabaseConnection();
  await db.query("INSERT INTO orders ... VALUES ...", [order.id, total]);

  // 4. Side Effects / Notification (External Integration)
  const emailClient = new EmailClient({ provider: "SendGrid" });
  await emailClient.send(order.email, "Order Confirmed", `Total: ${total}`);

  return { success: true, amount: total };
}

Why is this function a "landmine" from a Senior's perspective?

• Maintainability Disaster: Today, the Business team says, "Let's drop SendGrid and switch to AWS SES to optimize costs." You open this function to change it. Tomorrow, Accounting says, "We need to change the VAT calculation formula for this item." You open this exact same function again. When a single function shoulders the interests of too many different stakeholders, the rate of regression bugs skyrockets.
• Suffocating Unit Tests: To test whether the 15% VIP discount logic works correctly, you are forced to mock both the Database connection and the Email Client. Writing the tests takes five times longer than writing the core logic. Usually, this results in the team... abandoning unit tests altogether.
• Zero Reusability: What if, on another screen (e.g., Checkout Preview), users just want to preview their total amount before buying? You can't call this function because it automatically inserts data into the DB and fires an email. The result? You copy-paste the calculation logic somewhere else. The codebase starts bloat and rot.

3. How a Senior "Refactors": Divide and Conquer to Restore Single Responsibility

To solve this problem, we need to extract the Layers of Responsibility. We will transform the main function into an Orchestrator that solely handles the workflow, while delegating specialized tasks to the experts (Services/Repositories).

TypeScript

// 1. Domain Service: Solely responsible for pricing calculations (Pure Logic, No Side Effects)
class PricingEngine {
  public calculateTotal(items: OrderItem[], vipCode?: string): number {
    let total = items.reduce((sum, item) => sum + (item.price * item.quantity), 0);
    if (vipCode) {
      total = total * 0.85;
    }
    return total;
  }
}

// 2. Data Access Layer: Solely responsible for Database communication
class OrderRepository {
  public async save(orderId: string, totalAmount: number): Promise {
    const db = await getDatabaseConnection();
    await db.query("INSERT INTO orders ...", [orderId, totalAmount]);
  }
}

// 3. Infrastructure Service: Solely responsible for third-party integrations (Email Server)
class NotificationService {
  public async sendOrderConfirmation(email: string, amount: number): Promise {
    const emailClient = new EmailClient({ provider: "AWS_SES" }); // Assuming we switched to AWS
    await emailClient.send(email, "Order Confirmed", `Total: ${amount}`);
  }
}

And here is how our Core Workflow runs after being cleaned up:

TypeScript

// Clean, explicit, and enterprise-ready
class OrderApplicationService {
  constructor(
    private pricingEngine: PricingEngine,
    private orderRepo: OrderRepository,
    private notificationService: NotificationService
  ) {}

  public async execute(order: any): Promise {
    // 1. Basic validation right at the entry point
    if (!order.items || order.items.length === 0) return false;

    // 2. Delegate tasks to the experts
    const totalAmount = this.pricingEngine.calculateTotal(order.items, order.vipCode);

    await this.orderRepo.save(order.id, totalAmount);

    await this.notificationService.sendOrderConfirmation(order.email, totalAmount);

    return true;
  }
}

4. The Price of Cleanliness: What Are the Trade-offs?

I always tell my team: In software architecture, there is no silver bullet. Every choice is a trade-off.

• The Cost: You will notice an increase in the number of files. Instead of 1 file, we now have 4. Instead of reading top-to-bottom in a single breath, you now have to jump across different classes to track the flow. At first glance, this might look like "over-engineering" for a small project.
• The ROI (Return on Investment): But when the project swells to 50 or 100 features, this organizational structure is the very thing that keeps it from collapsing. Writing Unit Tests for the PricingEngine is now a breeze and runs in less than a millisecond because it is a Pure Function with zero I/O (DB, Network) bottlenecks.

- When you need to change infrastructure (e.g., swapping DBs or Email Providers), the risk of impacting the Core Business Logic is exactly zero.

Canonical URL: https://manulx.blog/en/posts/understanding-single-responsibility-principle
This document is provided by Manul X for AI agents under the llmstxt.org convention. Cite back to the canonical URL above.