nonobie — Real dev skills, explained like a friend would

What you'll learn

By the end of this chapter you will:

Apply SOLID principles to identify and fix badly-structured NestJS code
Distinguish between DRY (avoid duplicate knowledge) and the wrong version (avoid similar-looking code)
Explain YAGNI and remove speculative features from a DTO
Use the resilience pattern table to pick the right strategy for a failing vendor call
Recite the 20 daily rules from memory and apply at least five right now

The why

Rules like "always validate at the boundary" or "never mutate shared " seem abstract until the day you inherit a codebase that ignored them. This chapter is the philosophy behind all the technical decisions in the previous 16 chapters. Read it once, then refer back when you're making a judgment call.

SOLID — five principles behind good code

SOLID is a set of five principles for writing code that's easy to change, test, and understand.

S — Single Responsibility

Every class or function does one thing and does it well.

// ❌ OrdersService does too much
class OrdersService {
  async create(dto) { /* order logic */ }
  async sendEmail(orderId) { /* email logic */ }  // belongs in EmailService
  async syncWithVendor(orderId) { /* vendor logic */ }  // belongs in VendorService
}
 
// ✅ Each service owns one domain
class OrdersService { /* only order business rules */ }
class EmailService { /* only email sending */ }
class VendorSyncService { /* only vendor API calls */ }

O — Open/Closed

Open for extension, closed for modification. Add new behavior without changing existing code.

// ❌ Adding a new payment method requires modifying this function
function processPayment(method: string) {
  if (method === 'card') { /* ... */ }
  if (method === 'upi') { /* ...

L — Liskov Substitution

A subclass should be usable wherever the parent class is expected. In NestJS: any class implementing an interface should be swappable with any other. This is why DI with interfaces is powerful — you can swap a real S3Service for a MockS3Service in tests without changing the code that uses it.

I — Interface Segregation

Don't force a class to implement methods it doesn't use. Keep interfaces small and focused.

// ❌ Fat interface — every implementer must implement everything
interface UserService {
  create(); update(); delete(); sendEmail(); generateReport();
}
 
// ✅ Small, focused interfaces
interface UserRepository { create(); update(); delete(); }
interface UserNotifier { sendEmail(); }

D — Dependency Inversion

Depend on abstractions, not concrete implementations. This is literally what NestJS's DI system does.

// ❌ Service creates its own dependency — can't test without a real DB
class OrdersService {
  private orderModel = new Order();  // hard-coded
}
 
// ✅ Dependency is injected — test can inject a mock
class OrdersService {
  constructor(
    @Inject('ORDER_REPOSITORY') private orderModel:

DRY — Don't Repeat Yourself (but read this carefully)

DRY means "every piece of knowledge should have a single, unambiguous representation in the system."

It does NOT mean "never write similar-looking code." These are different things.

💡When NOT to DRY

// Two functions that look similar but represent DIFFERENT knowledge
// Do NOT merge them into one "generic" function
async getOrderById(id: string, userId: string) {
  return this.orderModel.findOne({ where

Tip

DRY is about knowledge, not code. Duplicate code that represents the same rule → fix it. Similar-looking code that represents different rules → leave it alone.

YAGNI — You Aren't Gonna Need It

Don't build features for imaginary future requirements. Build what's needed today, cleanly, so it's easy to extend later.

// ❌ YAGNI violation — building "just in case" features
interface CreateOrderDto {
  restaurantId: string;
  items: OrderItemDto[];
  future_batch_mode?: boolean;       // no one asked for this
  legacy_system_ref?: string;        // "might need someday"
  multi_currency_mode

Fail fast, fail loud

When something is wrong, find out immediately and loudly — not 3 hours later when a customer calls.

Validate config on startup (Chapter 11) — crash immediately if JWT_SECRET is missing
Validate at the boundary (Chapter 9) — reject bad input before it touches the database
Use assertions in tests for exact expected behavior — don't be lenient

// ❌ Silent failure — the bug hides until a user sees wrong data
const amount = parseFloat(dto.amount) || 0;  // if amount is 'abc', you process 0
 
// ✅ Loud failure — you find out immediately
const amount = parseFloat(dto.amount);
if (isNaN

Make the wrong thing hard

Structure your code so that the easy path is the correct path.

Make all repositories require a transaction parameter (can't accidentally forget it)
Make ValidationPipe global (can't accidentally skip )
Make @UseGuards(JwtGuard) required per-route

If forgetting a rule causes an immediate error — a compile error, a test failure, an app crash on startup — you get the feedback before it reaches production. If forgetting a rule is silent, it will reach production.

Boring stack wins

This is a fintech app with real money. This is not the place to use the latest experimental framework.

Tip

Node.js + NestJS + PostgreSQL + Redis: not the newest, not the fastest — but battle-tested and with solutions for every problem. PostgreSQL is 30 years old. That's not old, that's proven.

Watch out

"Let me use this new serverless DB that just came out of beta." In a user-facing food delivery app, boring beats clever every time. Don’t be the person who introduced an experimental dependency that took down the whole platform.

Resilience patterns — surviving external failures

When calling external services (vendor APIs, mail servers, payment gateways), assume they will fail.

Pattern	What it does	Use when
Timeout	Give up if call takes too long	Every outbound HTTP call
Retry with backoff	Try again, wait longer each time	Transient failures (vendor returns 503)
Circuit Breaker	Stop calling a failing service temporarily	Vendor is reliably down
Bulkhead	Isolate failures (one vendor's problems don't affect other vendors)	Multiple vendor integrations
Idempotency	Same operation → same result (safe to retry)	jobs, payment charges
Dead-letter queue	Capture permanently failing jobs for manual review	Queue workers

20 Daily Rules — print these out

Validate at the boundary. Never trust input you didn't validate with class-validator.
Use transactions for anything that touches >1 table.
Never access process.env directly in services. Use configService.get().
Never log passwords, tokens, or PII.
Always include a trace_id in log messages.
Add an before writing a query that filters on a column.
Write migrations forward-only. Never edit a merged migration.
New nullable columns first, backfill, then add NOT NULL constraint.
All jobs must be .
Use @UseGuards(JwtGuard) on every endpoint. No exceptions.
Check resource ownership in the service layer, not just by token.
Keep controllers thin (≤15 lines). Logic belongs in services.
Keep services focused (≤200 lines). If bigger, split.
Use successResponse() / errorResponse(). No raw objects.
Never use console.log in production code. Use the Winston logger.
Write the sad-path test before the happy-path test.
Before adding a new service or module, check if one already exists.
If a query has a Seq Scan on a large table — add an index.
Tag every image with the git SHA. Never use latest in production.
Run migrations before deployment, never after.

Appendix A — Starter file tree for a new module

plaintext

src/modules/
├── orders/
│   ├── orders.controller.ts
│   ├── orders.controller.spec.ts
│   ├── orders.service.ts
│   ├── orders.service.spec.ts
│   ├── orders.repository.ts
│   ├── orders.module.ts
│   └── dto/
│       ├── create-order.dto.ts
│       ├── update-order.dto.ts
│       └── order.response.ts
├── restaurants/
├── users/
└── payments/
 
src/database/
└── models/

│ └── my-feature.model.ts └── providers/ │ └── model-repository.provider.ts └── models/index.ts

-script/ └── 2026-05-01_add_my_feature_table.sql