Chapter 4: Providers & Services

Providers are the backbone of NestJS’s dependency injection system. They enable you to write modular, testable, and maintainable code. The most common provider is a service, which contains business logic and data access code. Think of providers as the “workers” in your application—they do the heavy lifting behind the scenes.

4.1 What is a Provider?

In NestJS, a provider is any class annotated with @Injectable(). Providers can be injected into controllers, other providers, or modules. They can be services, repositories, factories, or even values.

Types of Providers

Services:

Contain business logic
Most common type of provider
Stateless (usually)
Orchestrate data flow

Repositories:

Abstract data access
Encapsulate database operations
Make testing easier
Can swap implementations

Factories:

Create instances dynamically
Handle complex initialization
Can be async

Values:

Configuration objects
Constants
Third-party library instances

Provider Characteristics

All providers share these characteristics:

Decorated with @Injectable()
Registered in a module’s providers array
Can be injected via constructor
Managed by NestJS DI container
Have a lifecycle (singleton, request-scoped, transient)

4.2 The Service Layer

The service layer encapsulates business logic and orchestrates data flow between controllers and repositories. Services should be focused on business rules, not HTTP or database details.

Service Responsibilities

Services handle:

Business Logic: Core application rules and workflows
Data Orchestration: Coordinate between multiple repositories
Validation: Business-level validation (beyond DTO validation)
Transformation: Transform data between layers
Integration: Call external services, APIs, etc.

Services should NOT handle:

HTTP concerns (controllers do this)
Database queries (repositories do this)
Request/response formatting (controllers/interceptors do this)

Analogy:

If your app is a hospital, the controller is the receptionist (takes patient information, routes them to the right department), the service is the doctor (diagnoses and prescribes treatment — the actual business logic), and the repository is the medical records room (stores and retrieves patient data). The receptionist never performs surgery, the doctor never files paperwork, and the records clerk never diagnoses patients. When you see a service calling res.status(200).json(...), or a controller running a SQL query, that is the equivalent of a doctor filing paperwork — the system works, but it is doing someone else’s job, and it will cause problems as the hospital scales.

Basic Service Structure

import { Injectable } from '@nestjs/common';
import { UserRepository } from './user.repository';
import { CreateUserDto } from './dto/create-user.dto';

@Injectable()
export class UsersService {
  constructor(private readonly userRepository: UserRepository) {}

  async create(dto: CreateUserDto) {
    // Business logic: validate business rules
    if (await this.userRepository.existsByEmail(dto.email)) {
      throw new Error('Email already exists');
    }

    // Business logic: apply business rules
    const user = await this.userRepository.create({
      ...dto,
      status: 'pending',  // Business rule: new users are pending
      createdAt: new Date(),
    });

    // Business logic: trigger side effects
    await this.sendWelcomeEmail(user);

    return user;
  }

  async findAll() {
    return this.userRepository.findAll();
  }

  private async sendWelcomeEmail(user: any) {
    // Integration with email service
    // ...
  }
}

Stateless Services

Services should be stateless when possible:

// Bad: Stateful service
@Injectable()
export class UsersService {
  private users: User[] = [];  // State in service

  create(user: User) {
    this.users.push(user);  // Modifying state
  }
}

// Good: Stateless service
@Injectable()
export class UsersService {
  constructor(private userRepository: UserRepository) {}

  async create(dto: CreateUserDto) {
    return this.userRepository.create(dto);  // Delegates to repository
  }
}

Why Stateless?

Easier to test
Thread-safe
Can be shared across requests
No side effects between calls

Best Practice: Keep services focused on business logic, not HTTP or database details. Services should be stateless when possible.

4.3 Repository Pattern

Repositories abstract data access, making it easy to swap databases or mock for tests. This pattern keeps your business logic decoupled from the database implementation.

Why Use Repositories?

Without a repository layer, your services end up littered with database-specific code. Imagine you start with PostgreSQL, then management says “we need to support DynamoDB for this module.” If your service calls this.dataSource.query('SELECT * FROM users') directly, you are rewriting business logic. If your service calls this.userRepository.findAll(), you only swap the repository implementation — the service never changes. Benefits:

Abstraction: Business logic does not depend on database — your service does not know (or care) if it is talking to PostgreSQL, MongoDB, or an in-memory array
Testability: Easy to mock repositories in tests — just provide a fake object with the same method signatures
Flexibility: Can swap database implementations without touching services — just register a different class for the same injection token
Separation of Concerns: Data access logic (query optimization, joins, caching) lives in one place
Reusability: Repository methods like findByEmail() or findActive() can be used by multiple services

Basic Repository

import { Injectable } from '@nestjs/common';
import { CreateUserDto } from './dto/create-user.dto';
import { User } from './entities/user.entity';

@Injectable()
export class UserRepository {
  // In a real app, this would use TypeORM, Prisma, etc.
  private users: User[] = [];

  async create(dto: CreateUserDto): Promise<User> {
    const user: User = {
      id: this.users.length + 1,
      ...dto,
      createdAt: new Date(),
    };
    this.users.push(user);
    return user;
  }

  async findAll(): Promise<User[]> {
    return this.users;
  }

  async findOne(id: number): Promise<User | null> {
    return this.users.find(u => u.id === id) || null;
  }

  async findByEmail(email: string): Promise<User | null> {
    return this.users.find(u => u.email === email) || null;
  }

  async update(id: number, data: Partial<User>): Promise<User> {
    const user = await this.findOne(id);
    if (!user) {
      throw new Error('User not found');
    }
    Object.assign(user, data);
    return user;
  }

  async remove(id: number): Promise<void> {
    const index = this.users.findIndex(u => u.id === id);
    if (index === -1) {
      throw new Error('User not found');
    }
    this.users.splice(index, 1);
  }
}

Repository with TypeORM

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { User } from './entities/user.entity';
import { CreateUserDto } from './dto/create-user.dto';

@Injectable()
export class UserRepository {
  constructor(
    @InjectRepository(User)
    private readonly repository: Repository<User>,
  ) {}

  async create(dto: CreateUserDto): Promise<User> {
    const user = this.repository.create(dto);
    return this.repository.save(user);
  }

  async findAll(): Promise<User[]> {
    return this.repository.find();
  }

  async findOne(id: number): Promise<User | null> {
    return this.repository.findOne({ where: { id } });
  }

  async findByEmail(email: string): Promise<User | null> {
    return this.repository.findOne({ where: { email } });
  }

  async update(id: number, data: Partial<User>): Promise<User> {
    await this.repository.update(id, data);
    return this.findOne(id);
  }

  async remove(id: number): Promise<void> {
    await this.repository.delete(id);
  }
}

Repository Interface Pattern

Define interfaces for better abstraction:

// interfaces/user-repository.interface.ts
export interface IUserRepository {
  create(dto: CreateUserDto): Promise<User>;
  findAll(): Promise<User[]>;
  findOne(id: number): Promise<User | null>;
  findByEmail(email: string): Promise<User | null>;
  update(id: number, data: Partial<User>): Promise<User>;
  remove(id: number): Promise<void>;
}

// repositories/user.repository.ts
@Injectable()
export class UserRepository implements IUserRepository {
  // Implementation...
}

// Usage with interface
@Injectable()
export class UsersService {
  constructor(
    @Inject('IUserRepository')
    private readonly userRepository: IUserRepository,
  ) {}
}

Tip: Always use repositories for data access. This makes your code easier to test and maintain. Repositories abstract away database details from your business logic.

4.4 Domain-Driven Design (DDD)

For complex applications, consider using Domain-Driven Design principles. DDD helps you model your business domain and organize code around business concepts.

DDD Building Blocks

Entities:

Objects with unique identity
Can change over time
Example: User, Order, Product

// entities/user.entity.ts
export class User {
  id: number;
  email: string;
  name: string;
  createdAt: Date;

  // Business methods
  changeEmail(newEmail: string) {
    if (!this.isValidEmail(newEmail)) {
      throw new Error('Invalid email');
    }
    this.email = newEmail;
  }

  private isValidEmail(email: string): boolean {
    return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
  }
}

Value Objects:

Immutable objects with no identity
Defined by their attributes
Example: Email, Money, Address

// value-objects/email.vo.ts
export class Email {
  private readonly value: string;

  constructor(email: string) {
    if (!this.isValid(email)) {
      throw new Error('Invalid email');
    }
    this.value = email;
  }

  toString(): string {
    return this.value;
  }

  private isValid(email: string): boolean {
    return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
  }
}

Aggregates:

Groups of related entities
Have a root entity (aggregate root)
Maintain consistency boundaries

// aggregates/order.aggregate.ts
export class Order {
  id: number;
  items: OrderItem[];
  total: number;

  addItem(product: Product, quantity: number) {
    const item = new OrderItem(product, quantity);
    this.items.push(item);
    this.calculateTotal();
  }

  private calculateTotal() {
    this.total = this.items.reduce(
      (sum, item) => sum + item.price * item.quantity,
      0,
    );
  }
}

Domain Services:

Business logic that doesn’t fit in entities
Stateless operations
Coordinate between multiple entities

// services/order-calculation.service.ts
@Injectable()
export class OrderCalculationService {
  calculateDiscount(order: Order, customer: Customer): number {
    // Complex business logic involving multiple entities
    if (customer.isVIP() && order.total > 1000) {
      return order.total * 0.1;  // 10% discount
    }
    return 0;
  }
}

Repositories:

Abstract data access
Work with aggregates
Provide domain-friendly interface

Diagram: Service & Repository Layers

Controller (HTTP Layer)
    ↓
Service (Business Logic Layer)
    ↓
Repository (Data Access Layer)
    ↓
Database (Persistence Layer)

Decision Framework — When to Introduce DDD:

Signal	Action
CRUD operations with simple validation	Standard service + repository is enough
Business rules span 2-3 entities (e.g., “discount applies if customer is VIP AND order is above threshold”)	Introduce domain services
You catch yourself writing the same validation in multiple services	Extract to a value object (e.g., `Email`, `Money`)
Entity state changes have side effects (send email, update cache)	Introduce domain events
Multiple developers argue about where logic belongs	Define aggregate boundaries
Your service file exceeds 500 lines	Break into domain services + application service

Service Architecture Comparison:

Pattern	Complexity	When to Use	File Count (per feature)
Controller + Service	Low	Simple CRUD, prototypes	2-3 files
Controller + Service + Repository	Medium	Most production apps	3-4 files
Controller + Service + Repository + DDD	High	Complex domains, large teams	6-10 files
Controller + CQRS + Event Sourcing	Very High	Event-driven systems, audit requirements	10-15 files

Start at the lowest complexity that solves your problem. Moving up the ladder later is straightforward if your module boundaries are clean.

4.5 Dependency Injection in Services

Services can depend on other services, repositories, or configuration providers. Use constructor injection for clarity and testability.

Injecting Dependencies

import { Injectable } from '@nestjs/common';
import { UserRepository } from './user.repository';
import { EmailService } from './email.service';
import { ConfigService } from '../config/config.service';

@Injectable()
export class UsersService {
  constructor(
    private readonly userRepository: UserRepository,
    private readonly emailService: EmailService,
    private readonly configService: ConfigService,
  ) {}
}

Service Depending on Service

@Injectable()
export class NotificationService {
  constructor(
    private readonly mailer: MailerService,
    private readonly smsService: SmsService,
  ) {}

  async sendWelcome(user: User) {
    await Promise.all([
      this.mailer.send(user.email, 'Welcome!'),
      this.smsService.send(user.phone, 'Welcome!'),
    ]);
  }
}

Optional Dependencies

import { Injectable, Optional, Inject } from '@nestjs/common';

@Injectable()
export class UsersService {
  constructor(
    @Optional()
    @Inject('LOGGER')
    private readonly logger?: LoggerService,
  ) {}

  log(message: string) {
    if (this.logger) {
      this.logger.log(message);
    }
  }
}

Property Injection (Not Recommended)

// Avoid: Property injection
@Injectable()
export class UsersService {
  @Inject()
  private userRepository: UserRepository;
}

// Prefer: Constructor injection
@Injectable()
export class UsersService {
  constructor(private readonly userRepository: UserRepository) {}
}

Why Constructor Injection?

Dependencies are explicit — glancing at the constructor tells you everything the class needs
Easier to test (you can see all dependencies and provide mocks for each)
TypeScript can infer types from constructor parameters, so NestJS can auto-resolve them
Fail fast — if a dependency is missing, the app crashes at startup, not when a user hits a specific route

Practical Rule of Thumb: If your constructor has more than 4-5 dependencies, your service is probably doing too much. Consider breaking it into smaller, more focused services. This is not a hard limit, but it is a reliable smell that something needs refactoring. Tip: Favor constructor injection over property injection for better testability and clarity. Property injection (@Inject() on a field) hides dependencies, making it unclear what a class needs to function.

4.6 Real-World Example: User Registration

Let’s see how services and repositories work together in a real-world scenario:

Complete Registration Flow

// auth/auth.service.ts
import { Injectable, ConflictException } from '@nestjs/common';
import { UsersService } from '../users/users.service';
import { MailerService } from '../mailer/mailer.service';
import { HashService } from '../hash/hash.service';
import { RegisterDto } from './dto/register.dto';

@Injectable()
export class AuthService {
  constructor(
    private readonly usersService: UsersService,
    private readonly mailer: MailerService,
    private readonly hashService: HashService,
  ) {}

  async register(dto: RegisterDto) {
    // Check if user exists
    const existingUser = await this.usersService.findByEmail(dto.email);
    if (existingUser) {
      throw new ConflictException('Email already registered');
    }

    // Hash password
    const hashedPassword = await this.hashService.hash(dto.password);

    // Create user
    const user = await this.usersService.create({
      ...dto,
      password: hashedPassword,
    });

    // Send welcome email (don't wait for it)
    this.mailer.sendWelcome(user.email).catch(err => {
      console.error('Failed to send welcome email:', err);
    });

    // Return user (without password)
    const { password, ...userWithoutPassword } = user;
    return userWithoutPassword;
  }
}

Supporting Services

// users/users.service.ts
@Injectable()
export class UsersService {
  constructor(private readonly userRepository: UserRepository) {}

  async create(dto: CreateUserDto): Promise<User> {
    return this.userRepository.create(dto);
  }

  async findByEmail(email: string): Promise<User | null> {
    return this.userRepository.findByEmail(email);
  }
}

// hash/hash.service.ts
import { Injectable } from '@nestjs/common';
import * as bcrypt from 'bcrypt';

@Injectable()
export class HashService {
  async hash(password: string): Promise<string> {
    const salt = await bcrypt.genSalt(10);
    return bcrypt.hash(password, salt);
  }

  async compare(password: string, hash: string): Promise<boolean> {
    return bcrypt.compare(password, hash);
  }
}

Diagram: Registration Flow

Controller (receives RegisterDto)
    ↓
AuthService.register()
    ↓
UsersService.findByEmail() → UserRepository
    ↓ (if not exists)
HashService.hash() → Hash password
    ↓
UsersService.create() → UserRepository → Database
    ↓
MailerService.sendWelcome() → Email Service
    ↓
Return user (without password)

4.7 Service Composition

Services can be composed to build complex workflows:

Orchestration Service

Orchestration services coordinate multiple services to complete a business workflow. They are the conductors of your application’s orchestra — they do not play any instrument themselves, but they make sure every musician plays at the right time, in the right order.

@Injectable()
export class OrderService {
  constructor(
    private readonly orderRepository: OrderRepository,
    private readonly paymentService: PaymentService,
    private readonly inventoryService: InventoryService,
    private readonly notificationService: NotificationService,
  ) {}

  async processOrder(orderDto: CreateOrderDto) {
    // Step 1: Check inventory BEFORE charging the customer.
    // Order matters here -- you never want to charge for out-of-stock items.
    const available = await this.inventoryService.checkAvailability(
      orderDto.items,
    );
    if (!available) {
      throw new Error('Items not available');
    }

    // Step 2: Process payment. If this fails, we have not created any
    // order or reserved any inventory -- clean failure.
    const payment = await this.paymentService.process(orderDto.payment);

    // Step 3: Create the order record. At this point, payment succeeded.
    const order = await this.orderRepository.create({
      ...orderDto,
      paymentId: payment.id,
      status: 'confirmed',
    });

    // Step 4: Reserve inventory. If this fails after payment, you need
    // a compensation strategy (refund). In production, wrap steps 2-4
    // in a saga or transaction. See Chapter 8 (Microservices) for patterns.
    await this.inventoryService.reserve(orderDto.items);

    // Step 5: Notifications are non-critical. Use fire-and-forget so a
    // failed email does not roll back a successful order.
    this.notificationService.sendOrderConfirmation(order).catch(err => {
      // Log but do not throw -- the order succeeded regardless
      console.error('Notification failed:', err);
    });

    return order;
  }
}

Common Mistake: Making every step awaited and letting any failure abort the entire flow. In reality, some steps (like notifications) are non-critical and should not block or fail the main transaction. Design your orchestration with failure modes in mind.

4.8 Error Handling in Services

Services should throw domain-specific exceptions:

import { Injectable, ConflictException, NotFoundException } from '@nestjs/common';

@Injectable()
export class UsersService {
  constructor(private readonly userRepository: UserRepository) {}

  async create(dto: CreateUserDto) {
    const existing = await this.userRepository.findByEmail(dto.email);
    if (existing) {
      throw new ConflictException('Email already exists');
    }
    return this.userRepository.create(dto);
  }

  async findOne(id: number) {
    const user = await this.userRepository.findOne(id);
    if (!user) {
      throw new NotFoundException(`User with ID ${id} not found`);
    }
    return user;
  }
}

4.9 Edge Cases in Service Design

Edge Case 1: Fire-and-forget operations that fail silently In the order processing example (section 4.7), we used .catch() for notifications. But what if the notification failure means the user never receives their order confirmation? You need a strategy for “important but non-blocking” operations: write them to a persistent queue (database table, Redis list, or message broker) and process them asynchronously with retries. Pure fire-and-forget with .catch(console.error) is only acceptable for truly non-critical side effects. Edge Case 2: Service methods that return different shapes A service method that returns User on success but throws NotFoundException on failure has a clear contract. But what about methods that can return null, undefined, or an empty array? Establish a convention early: return null for “not found” in repository methods and throw NotFoundException in service methods. Never let null propagate to the controller — that results in a 200 response with an empty body, which is confusing for API consumers. Edge Case 3: Circular service dependencies AuthService needs UsersService to validate credentials. UsersService needs AuthService to hash passwords on user creation. This is a real circular dependency. The fix is not forwardRef — it is extracting HashService into its own module that both can import. When you see a circular dependency, ask: “What is the shared concern?” Extract it into its own service. Edge Case 4: Long-running service methods and request timeouts If a service method takes 30 seconds (generating a report, processing a large file), the HTTP request will likely timeout before it completes. Options: (1) return a 202 Accepted with a job ID immediately, then poll for status; (2) use WebSockets to push the result; (3) use a background job queue like Bull. Never make the client wait for long-running operations synchronously.

4.9 Best Practices

Following best practices ensures your services are maintainable and testable.

Keep Services Stateless

// Bad: Stateful
@Injectable()
export class UsersService {
  private cache = new Map();
}

// Good: Stateless
@Injectable()
export class UsersService {
  constructor(private cacheService: CacheService) {}
}

Use Repositories for Data Access

// Bad: Direct database access in service
@Injectable()
export class UsersService {
  constructor(private dataSource: DataSource) {}

  async findAll() {
    return this.dataSource.query('SELECT * FROM users');
  }
}

// Good: Use repository
@Injectable()
export class UsersService {
  constructor(private userRepository: UserRepository) {}

  async findAll() {
    return this.userRepository.findAll();
  }
}

Favor Constructor Injection

// Good: Constructor injection
@Injectable()
export class UsersService {
  constructor(private userRepository: UserRepository) {}
}

Write Unit Tests

describe('UsersService', () => {
  let service: UsersService;
  let repository: UserRepository;

  beforeEach(async () => {
    const module = await Test.createTestingModule({
      providers: [
        UsersService,
        {
          provide: UserRepository,
          useValue: {
            create: jest.fn(),
            findAll: jest.fn(),
          },
        },
      ],
    }).compile();

    service = module.get(UsersService);
    repository = module.get(UserRepository);
  });

  it('should create user', async () => {
    const dto = { name: 'John', email: 'john@example.com' };
    const user = { id: 1, ...dto };

    jest.spyOn(repository, 'create').mockResolvedValue(user);

    const result = await service.create(dto);
    expect(result).toEqual(user);
    expect(repository.create).toHaveBeenCalledWith(dto);
  });
});

Use Interfaces for Testability

// Define interface
export interface IUserRepository {
  create(dto: CreateUserDto): Promise<User>;
}

// Implement interface
@Injectable()
export class UserRepository implements IUserRepository {
  // ...
}

// Use interface in service
@Injectable()
export class UsersService {
  constructor(
    @Inject('IUserRepository')
    private userRepository: IUserRepository,
  ) {}
}

Avoid Circular Dependencies

// Bad: Circular dependency
// UsersService depends on OrdersService
// OrdersService depends on UsersService

// Good: Extract shared logic
// Create OrderService that doesn't depend on UsersService
// Or use forwardRef() if necessary

Separate Business Logic from Data Access

// Bad: Business logic in repository
@Injectable()
export class UserRepository {
  async createUserWithValidation(dto: CreateUserDto) {
    // Business validation in repository
    if (dto.email.includes('@')) {
      // ...
    }
  }
}

// Good: Business logic in service
@Injectable()
export class UsersService {
  async create(dto: CreateUserDto) {
    // Business validation in service
    if (!this.isValidEmail(dto.email)) {
      throw new Error('Invalid email');
    }
    return this.userRepository.create(dto);
  }
}

4.10 Summary

You’ve learned how to structure business logic using providers, services, and repositories: Key Concepts:

Providers: Injectable classes that provide functionality
Services: Contain business logic and orchestrate workflows
Repositories: Abstract data access from business logic
DDD: Domain-Driven Design patterns for complex applications
Dependency Injection: Services depend on other services/repositories

Best Practices:

Keep services stateless
Use repositories for all data access
Favor constructor injection
Write unit tests for services
Use interfaces for testability
Avoid circular dependencies
Separate business logic from data access

Next Chapter: Learn about database integration with TypeORM and Prisma, including migrations, transactions, and query optimization.

Interview Deep-Dive

What is the repository pattern, and why would you add a repository layer between your service and TypeORM/Prisma instead of calling the ORM directly?

Strong Answer:

The repository pattern abstracts data access behind an interface, so your service says this.userRepository.findByEmail(email) instead of this.prisma.user.findUnique({ where: { email } }). The service does not know or care whether the data comes from PostgreSQL, MongoDB, or an in-memory array.
The primary benefit is testability. Without a repository, testing a service means mocking the entire Prisma client or TypeORM repository with all their methods. With a custom repository, you mock a simple interface with 5-6 methods that you control.
The second benefit is portability. I worked on a project that started with TypeORM and needed to migrate to Prisma after TypeORM’s performance on complex joins became a bottleneck. Because we had a repository layer, the migration was contained: we rewrote 12 repository files, and the 40+ service files never changed.
The trade-off is indirection. For a simple CRUD app with 5 entities, the repository layer adds boilerplate with little benefit. My rule of thumb: add a repository layer when (1) your service needs to be tested without a database, (2) you might swap ORMs, or (3) your queries are complex enough to warrant encapsulation.
A common anti-pattern is putting business logic in the repository. The repository should only answer “get me this data” or “save this data.” Deciding whether a user is allowed to update their profile is business logic that belongs in the service.

Follow-up: TypeORM already has a Repository class via @InjectRepository(). Why would you wrap it in your own custom repository?TypeORM’s built-in repository exposes the entire QueryBuilder API, which means your service can construct arbitrary SQL. A custom repository hides these details behind methods like findWithPosts(userId), so the service never touches the query builder. Additionally, custom repository methods are self-documenting — findActiveByRole('admin') is more readable than a 10-line query builder chain scattered across multiple service methods.

Your OrderService depends on PaymentService, InventoryService, NotificationService, and AuditService. A colleague says this is too many dependencies. How would you refactor?

Strong Answer:

Four to five constructor dependencies is at the edge. The question is: does the OrderService genuinely need to orchestrate all four concerns, or has it accumulated responsibilities over time?
First, check if any dependencies are cross-cutting concerns. AuditService is a prime candidate — audit logging could be handled by an interceptor instead of explicit service calls. That removes one dependency.
NotificationService is another candidate for extraction. Sending a confirmation email is a side effect, not core order creation logic. If the email service is down, should the order fail? Usually not. Move it to an event handler: OrderService emits an OrderCreatedEvent, and NotificationService listens for it asynchronously. This decouples the two and removes another dependency.
After refactoring, OrderService has two dependencies: PaymentService and InventoryService. These are genuinely part of the order creation workflow.
The general rule: if your constructor has more than 4-5 dependencies, check whether some are cross-cutting concerns that can be moved to interceptors, event handlers, or middleware. If all are genuinely part of core business logic, the service might be an orchestrator, which is a valid pattern.

Follow-up: How do you handle the case where payment succeeds but inventory reservation fails?This is the distributed transaction problem. The solution is the Saga pattern: define compensation actions for each step. If inventory reservation fails after payment succeeds, trigger a RefundPaymentCommand to reverse the charge. In NestJS, implement this with the @nestjs/cqrs event bus — the OrderSaga listens for PaymentSucceededEvent and InventoryReservationFailedEvent, and dispatches compensation commands.

Should NestJS services throw HTTP exceptions like NotFoundException, or domain-specific errors? Defend your position.

Strong Answer:

My position: services should throw HTTP exceptions for typical REST APIs, and domain exceptions for complex or multi-transport applications.
The pragmatic argument for HTTP exceptions: in a typical REST API, the service and HTTP layer are deployed together. NotFoundException maps directly to 404. If the service throws a generic Error('User not found'), the controller has to catch and convert it — that is boilerplate with no benefit.
The purist argument for domain exceptions: if your service is used by both an HTTP controller and a gRPC handler, NotFoundException is meaningless in gRPC. A domain exception like UserNotFoundError can be mapped to 404 in the HTTP exception filter and to NOT_FOUND in the gRPC filter.
My practical rule: if the application only has an HTTP API and is unlikely to add other transports, throw HttpException subclasses directly. If it has multiple transports or uses DDD principles, create domain exception classes and map them in transport-specific filters.
The one thing I would never do is throw raw Error objects. They carry no semantic meaning, and the exception filter has to guess the status code.

Follow-up: How would you implement a custom exception hierarchy for an application serving both REST and gRPC?Create a base DomainException class with a code property (like USER_NOT_FOUND). Subclass it for specific errors. Then create two exception filters: an HttpDomainExceptionFilter mapping codes to HTTP statuses, and a GrpcDomainExceptionFilter mapping to gRPC status codes. Register each on its respective transport. The service throws domain exceptions, and each transport handles the mapping independently.

How do you structure a NestJS service layer for a domain with complex business rules, like a loan approval system?

Strong Answer:

For complex domains, I use Domain-Driven Design principles within NestJS’s service layer. The key distinction is between application services (orchestrate workflows) and domain services (encapsulate business rules that span multiple entities).
The loan approval system would have a LoanApplicationService (application service) that orchestrates the workflow: receive application, run credit check, calculate risk score, apply underwriting rules. It injects domain services like CreditScoringService and UnderwritingService.
The domain logic lives in entities and value objects. The LoanApplication entity has methods like approve(), deny(reason), requestAdditionalDocuments(). These enforce invariants: you cannot approve an application that has not passed underwriting. This is a “rich domain model.”
Value objects like Money, InterestRate, CreditScore encapsulate validation. new CreditScore(850) succeeds, new CreditScore(-1) throws. This prevents invalid data from propagating.
The anti-pattern to avoid is an “anemic domain model” where entities are just data containers and all logic is in the service. This leads to 500-line service methods that are hard to test.

Follow-up: How do you test business rules that span multiple entities without hitting the database?Create entities in memory using plain constructors (new LoanApplication({ amount: 50000, creditScore: new CreditScore(720) })), call domain methods, and assert results. Since entities are plain classes with no DI, they are trivially testable. For domain services, inject mocked repositories. The test reads like a specification: “Given a credit score of 720 and amount of 50,000, when underwriting rules are applied, the application should be approved at 4.5%.”

​Chapter 4: Providers & Services

​4.1 What is a Provider?

​Types of Providers

​Provider Characteristics

​4.2 The Service Layer

​Service Responsibilities

​Basic Service Structure

​Stateless Services

​4.3 Repository Pattern

​Why Use Repositories?

​Basic Repository

​Repository with TypeORM

​Repository Interface Pattern

​4.4 Domain-Driven Design (DDD)

​DDD Building Blocks

​4.5 Dependency Injection in Services

​Injecting Dependencies

​Service Depending on Service

​Optional Dependencies

​Property Injection (Not Recommended)

​4.6 Real-World Example: User Registration

​Complete Registration Flow

​Supporting Services

​4.7 Service Composition

​Orchestration Service

​4.8 Error Handling in Services

​4.9 Edge Cases in Service Design

​4.9 Best Practices

​Keep Services Stateless

​Use Repositories for Data Access

​Favor Constructor Injection

​Write Unit Tests

​Use Interfaces for Testability

​Avoid Circular Dependencies

​Separate Business Logic from Data Access

​4.10 Summary

​Interview Deep-Dive

Chapter 4: Providers & Services

4.1 What is a Provider?

Types of Providers

Provider Characteristics

4.2 The Service Layer

Service Responsibilities

Basic Service Structure

Stateless Services

4.3 Repository Pattern

Why Use Repositories?

Basic Repository

Repository with TypeORM

Repository Interface Pattern

4.4 Domain-Driven Design (DDD)

DDD Building Blocks

4.5 Dependency Injection in Services

Injecting Dependencies

Service Depending on Service

Optional Dependencies

Property Injection (Not Recommended)

4.6 Real-World Example: User Registration

Complete Registration Flow

Supporting Services

4.7 Service Composition

Orchestration Service

4.8 Error Handling in Services

4.9 Edge Cases in Service Design

4.9 Best Practices

Keep Services Stateless

Use Repositories for Data Access

Favor Constructor Injection

Write Unit Tests

Use Interfaces for Testability

Avoid Circular Dependencies

Separate Business Logic from Data Access

4.10 Summary

Interview Deep-Dive