System Design (LLD)Domain Services

Domain Services in Domain-Driven Design

LevelAdvanced

Duration55 mins

TopicDomain Services

3 / 4

Domain Service vs Application Service

The Most Common DDD Confusion

Ask a developer what a 'service' is in their codebase, and you'll get different answers. One developer's 'domain service' is another's 'application service.' This confusion isn't just semantic pedantry—it leads to misplaced logic, leaky abstractions, and tangled architectures.

The distinction between Domain Services and Application Services is one of the most important—and most frequently misunderstood—concepts in DDD. Getting it wrong means putting domain logic where it doesn't belong, or worse, scattering business rules across multiple layers where they become inconsistent and unmaintainable.

This page will make the distinction crystal clear, with concrete examples and decision frameworks you can apply immediately.

What You Will Learn

By the end of this page, you will understand the fundamental difference between Domain Services and Application Services, know which type of logic belongs in each, and have a clear decision framework for placing new services correctly in your architecture.

The Fundamental Distinction

At its core, the distinction is about what the service cares about:

Domain Service: Encapsulates business logic and domain rules that don't belong to a single entity. It knows domain concepts and enforces domain invariants.

Application Service: Orchestrates the use of domain objects to fulfill application use cases. It knows application workflow but delegates business rules to the domain.

Think of it this way: A Domain Service answers the question "How does the business work?" An Application Service answers the question "How does the application coordinate work?"

Domain Service

•Contains business logic
•Encapsulates domain rules
•Operates on domain objects
•Part of the domain model
•Has no knowledge of:
•• HTTP/REST/GraphQL
•• Transactions (explicit)
•• Authorization/Authentication
•• Logging infrastructure
•• External service protocols

Application Service

•Contains orchestration logic
•Coordinates use case workflow
•Uses domain objects (doesn't contain logic about them)
•Part of the application layer
•Responsible for:
•• Transaction boundaries
•• Authorization checks
•• Input validation (format, not business)
•• DTO conversion
•• Cross-cutting concerns

The 'Would Domain Experts Care?' Test

Here's a quick heuristic: Would domain experts care about this logic? If yes, it's probably domain logic (entity or domain service). If the logic is purely about application mechanics (authorization, transactions, converting DTOs)—things domain experts don't think about—it's application service territory.

A Concrete Example: Money Transfer

Let's trace a complete money transfer use case through both service types to see how responsibilities divide:

Scenario: A REST API receives a request to transfer $100 from account A to account B.

transfer-architecture.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
// ============================================
// Controller (Infrastructure Layer)
// ============================================
@Controller('/transfers')
class TransferController {
    constructor(private transferAppService: TransferApplicationService) {}
    
    @Post()
    async createTransfer(@Body() dto: CreateTransferDto): Promise<TransferResponseDto> {
        // Controller only handles HTTP concerns
        const result = await this.transferAppService.executeTransfer(
            dto.sourceAccountId,
            dto.destinationAccountId,
            dto.amount,
            dto.currency
        );
        return TransferResponseDto.fromDomain(result);
    }
}
 
// ============================================
// Application Service (Application Layer)
// ============================================
@Injectable()
class TransferApplicationService {
    constructor(
        private accountRepository: AccountRepository,
        private fundsTransferService: FundsTransferService,  // Domain Service
        private unitOfWork: UnitOfWork,
        private authorizationService: AuthorizationService,
        private eventBus: EventBus
    ) {}
    
    @Transactional()  // Transaction boundary - Application responsibility
    async executeTransfer(
        sourceId: string,
        destId: string,
        amount: number,
        currency: string
    ): Promise<TransferResult> {
        // 1. Authorization - Application concern
        await this.authorizationService.ensureCanTransfer(
            this.currentUser,
            sourceId
        );
        
        // 2. Load domain objects
        const source = await this.accountRepository.findById(new AccountId(sourceId));
        const destination = await this.accountRepository.findById(new AccountId(destId));
        
        if (!source || !destination) {
            throw new AccountNotFoundError();
        }
        
        // 3. Create domain value object
        const money = Money.of(amount, Currency.from(currency));
        
        // 4. DELEGATE to Domain Service for business logic
        const result = this.fundsTransferService.transfer(source, destination, money);
        
        // 5. Persist changes
        await this.accountRepository.save(source);
        await this.accountRepository.save(destination);
        
        // 6. Publish integration events - Application concern
        await this.eventBus.publish(new TransferCompletedEvent(result));
        
        return result;
    }
}

domain-service.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// ============================================
// Domain Service (Domain Layer)
// ============================================
 
// Interface defined in domain layer
interface FundsTransferService {
    transfer(source: Account, destination: Account, amount: Money): TransferResult;
}
 
// Implementation - pure domain logic
class FundsTransferServiceImpl implements FundsTransferService {
    constructor(
        private transferPolicy: TransferPolicyProvider,
        private feeCalculator: TransferFeeCalculator  // Another domain service
    ) {}
    
    transfer(source: Account, destination: Account, amount: Money): TransferResult {
        // ALL business rules live here in the domain
        
        // 1. Check transfer policy (domain rule)
        const policy = this.transferPolicy.getPolicyFor(source, destination);
        if (!policy.allowsTransfer(amount)) {
            throw new TransferPolicyViolationError(policy.reason);
        }
        
        // 2. Check source account constraints (domain rule)
        if (!source.canWithdraw(amount)) {
            throw new InsufficientFundsError(source.id, amount);
        }
        
        // 3. Check destination account constraints (domain rule)
        if (!destination.canReceive(amount)) {
            throw new AccountCannotReceiveError(destination.id, amount);
        }
        
        // 4. Calculate fees (domain calculation)
        const fees = this.feeCalculator.calculateFees(source, destination, amount);
        
        // 5. Execute the domain operation
        source.withdraw(amount.add(fees));
        destination.credit(amount);
        
        // 6. Return domain result
        return new TransferResult(
            TransferId.generate(),
            source.id,
            destination.id,
            amount,
            fees,
            TransferStatus.COMPLETED
        );
    }
}

Notice the clean separation:

Application Service handles: Authorization, transaction boundaries, repository calls, DTO conversion, event publishing
Domain Service handles: Business rules, domain invariants, fee calculations, the actual transfer logic

The Application Service uses the Domain Service but doesn't replicate its logic. The Domain Service knows nothing about HTTP, transactions, or event buses.

Common Mistakes and How to Fix Them

Let's examine the most common mistakes developers make when distinguishing these service types.

Mistake 1: Putting Business Logic in Application Services

This is the most common error—and it leads directly to the Anemic Domain Model anti-pattern:

mistake-1.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// ❌ WRONG: Business logic in Application Service
class OrderApplicationService {
    async placeOrder(dto: PlaceOrderDto): Promise<OrderDto> {
        // Authorization - OK, this belongs here
        await this.authService.ensureCanPlaceOrder(this.currentUser);
        
        // Business logic - WRONG, should be in domain
        if (dto.items.length === 0) {
            throw new Error("Order must have items");  // Domain rule leaked!
        }
        
        // More business logic - WRONG
        let total = 0;
        for (const item of dto.items) {
            const product = await this.productRepo.findById(item.productId);
            if (product.stock < item.quantity) {
                throw new Error("Insufficient stock");  // Domain rule leaked!
            }
            total += product.price * item.quantity;
        }
        
        // Discount logic - WRONG
        if (total > 100) {
            total = total * 0.9;  // Domain rule leaked!
        }
        
        // ... save order ...
    }
}
 
// ✅ CORRECT: Domain logic in Domain layer
class OrderApplicationService {
    async placeOrder(dto: PlaceOrderDto): Promise<OrderDto> {
        await this.authService.ensureCanPlaceOrder(this.currentUser);
        
        // Create domain objects
        const order = Order.create(this.currentUser.customerId);
        for (const item of dto.items) {
            const product = await this.productRepo.findById(item.productId);
            order.addItem(product, item.quantity);  // Domain validates internally
        }
        
        // Let domain service handle business logic
        this.orderPricingService.applyPricing(order);  // Domain service
        await this.inventoryService.reserveForOrder(order);  // Domain service
        
        await this.orderRepo.save(order);
        return OrderDto.from(order);
    }
}

Mistake 2: Making Domain Services Depend on Infrastructure

Domain Services should be pure domain. When they know about frameworks, databases, or external services, they become tangled with infrastructure:

mistake-2.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// ❌ WRONG: Domain Service with infrastructure dependencies
class PricingDomainService {
    constructor(
        private httpClient: HttpClient,      // ❌ Infrastructure!
        private database: Database,          // ❌ Infrastructure!
        private logger: Logger              // ❌ Infrastructure!
    ) {}
    
    async calculatePrice(order: Order): Promise<Money> {
        this.logger.info("Calculating price...");  // ❌ Infrastructure concern
        
        // Direct database access from domain
        const rates = await this.database.query(
            'SELECT * FROM tax_rates WHERE region = ?',
            [order.region]
        );  // ❌ SQL in domain!
        
        // HTTP call from domain
        const exchangeRate = await this.httpClient.get(
            'https://api.exchange.com/rate'
        );  // ❌ HTTP in domain!
        
        // calculation...
    }
}
 
// ✅ CORRECT: Domain Service with domain abstractions
interface TaxRateProvider {
    getRatesFor(region: Region): TaxRate[];
}
 
interface ExchangeRateProvider {
    getRate(from: Currency, to: Currency): ExchangeRate;
}
 
class PricingDomainService {
    constructor(
        private taxRateProvider: TaxRateProvider,     // Domain interface
        private exchangeProvider: ExchangeRateProvider // Domain interface
    ) {}
    
    calculatePrice(order: Order): Money {
        const rates = this.taxRateProvider.getRatesFor(order.region);
        const rate = this.exchangeProvider.getRate(order.currency, baseCurrency);
        
        // Pure domain calculation using domain abstractions
        return this.computePrice(order, rates, rate);
    }
}

Mistake 3: Using Domain Services for CRUD Operations

Simple create, read, update, delete operations don't need Domain Services:

mistake-3.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// ❌ WRONG: Domain Service for simple CRUD
class CustomerDomainService {
    createCustomer(name: string, email: string): Customer {
        return new Customer(name, email);  // This is just construction
    }
    
    updateCustomerEmail(customer: Customer, email: string): void {
        customer.email = email;  // This should be a method ON Customer
    }
}
 
// ✅ CORRECT: Entity handles its own simple operations
class Customer {
    constructor(
        private name: CustomerName,
        private email: EmailAddress
    ) {}
    
    changeEmail(newEmail: EmailAddress): void {
        this.email = newEmail;
        // Possibly raise CustomerEmailChanged event
    }
}
 
// Application Service for the use case
class CustomerApplicationService {
    async changeEmail(customerId: string, newEmail: string): Promise<void> {
        const customer = await this.customerRepo.findById(customerId);
        customer.changeEmail(new EmailAddress(newEmail));
        await this.customerRepo.save(customer);
    }
}

The 'Service' Suffix Trap

Just because a class ends in 'Service' doesn't define what type it is. A class called 'OrderService' could be a domain service, application service, or infrastructure service. The name alone tells you nothing—the responsibilities and dependencies do.

The Layer Test: Where Does This Service Belong?

Here's a systematic decision framework for placing services correctly. For each potential service, ask these questions in order:

Service Placement Decision Framework

•Does this logic belong to a single entity? → If yes, put it IN that entity. Not a service at all.
•Is this purely about application workflow? (transactions, authorization, DTO mapping, coordinating calls) → Application Service
•Is this business logic involving multiple domain objects? → Domain Service
•Does this require infrastructure access but no domain logic? → Infrastructure Service
•Does this implement a domain interface using infrastructure? → Infrastructure implementation of Domain Service interface

Quick Reference: Where Does This Logic Go?
Type of Logic	Where It Goes	Example
Single entity's behavior	Entity method	order.cancel(), customer.changeAddress()
Use case orchestration	Application Service	PlaceOrderAppService, CheckoutAppService
Transaction management	Application Service	@Transactional decorator or explicit UoW
Authorization	Application Service	Before calling domain logic
Business calculation across objects	Domain Service	PricingService, MatchingService
Domain rules spanning aggregates	Domain Service	FundsTransferService
External API integration	Infrastructure Service	ExternalPaymentGateway implementation
Database access	Repository implementation	PostgresOrderRepository

placement-examples.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
// Complete layer separation example
 
// DOMAIN LAYER -----------------------------
// 1. Entity with its own logic
class Order {
    private items: OrderItem[];
    private status: OrderStatus;
    
    addItem(product: Product, qty: Quantity): void { /* entity logic */ }
    cancel(): void { /* entity logic */ }
    calculateSubtotal(): Money { /* entity can calculate from own data */ }
}
 
// 2. Domain Service for cross-entity logic
interface ShippingCostCalculator {
    calculate(order: Order, destination: Address, carrier: Carrier): Money;
}
 
// 3. Domain Service for complex business rules
interface InventoryAllocationService {
    allocateInventory(order: Order): AllocationResult;
}
 
// APPLICATION LAYER ------------------------
class PlaceOrderApplicationService {
    constructor(
        private orderRepo: OrderRepository,
        private inventoryService: InventoryAllocationService,  // Domain
        private shippingCalculator: ShippingCostCalculator,    // Domain
        private paymentGateway: PaymentGateway,                // Infra interface
        private emailSender: EmailSender                       // Infra interface
    ) {}
    
    @Transactional()  // ← Application concern
    @Authorized(['place-order'])  // ← Application concern
    async placeOrder(dto: PlaceOrderDto): Promise<OrderDto> {
        // Orchestration, not business logic
        const order = Order.create(dto.customerId);
        
        for (const item of dto.items) {
            order.addItem(/* ... */);
        }
        
        // Delegate to domain services
        const allocation = await this.inventoryService.allocateInventory(order);
        const shipping = this.shippingCalculator.calculate(
            order, dto.destination, dto.carrier
        );
        
        // Delegate to infrastructure
        await this.paymentGateway.charge(order.total());
        
        await this.orderRepo.save(order);
        await this.emailSender.sendOrderConfirmation(order);  // Infra
        
        return OrderDto.from(order);
    }
}
 
// INFRASTRUCTURE LAYER ---------------------
// Implements domain interface with infrastructure
class StripePaymentGateway implements PaymentGateway {
    async charge(amount: Money): Promise<PaymentResult> {
        // Stripe API calls - pure infrastructure
    }
}

The Dependency Direction

Understanding the difference between Domain and Application Services is easier when you visualize the dependency direction in a layered architecture:

The Dependency Rule: Higher-level layers depend on lower-level layers. The domain layer depends on nothing external (it's the core).

[ Controllers / UI ]      →  HTTP, views, CLI
        ↓
[ Application Services ]  →  Use cases, orchestration, transactions
        ↓
[ Domain Services ]       →  Business logic, domain operations
        ↓
[ Entities / VOs ]        →  Core domain concepts, business rules
        ↓
[ Domain Interfaces ]     →  Contracts for infrastructure
        ↑
[ Infrastructure ]        →  DB, APIs, files (IMPLEMENTS domain interfaces)

Key Relationship Rules

•Application Services CALL Domain Services — Application uses domain to fulfill use cases
•Domain Services use Domain objects — Entities, value objects, domain interfaces only
•Domain layer NEVER imports from Application — Domain is pure, knows nothing about use cases
•Infrastructure IMPLEMENTS Domain interfaces — Dependency inversion in action
•Application coordinates Infrastructure and Domain — It's the glue between them

imports-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// ============================================
// DOMAIN LAYER - knows ONLY domain
// ============================================
 
// domain/services/funds-transfer-service.ts
import { Account } from '../entities/account';
import { Money } from '../value-objects/money';
import { TransferPolicy } from '../policies/transfer-policy';
// ❌ NEVER: import { TransferAppService } from '@app/services';
// ❌ NEVER: import { Database } from 'typeorm';
// ❌ NEVER: import { HttpClient } from '@nestjs/common';
 
export class FundsTransferService {
    // Pure domain implementation
}
 
// ============================================
// APPLICATION LAYER - coordinates all
// ============================================
 
// application/services/transfer-app-service.ts
import { FundsTransferService } from '@domain/services';  // ✅ Uses domain
import { AccountRepository } from '@domain/repositories';  // ✅ Domain interface
import { TransferResult } from '@domain/results';         // ✅ Domain type
import { TransferDto } from '../dtos/transfer-dto';       // ✅ App layer DTO
import { Transactional } from '@infrastructure/decorators'; // ✅ Uses infra
 
export class TransferApplicationService {
    constructor(
        private domainService: FundsTransferService,  // Domain dependency
        private accountRepo: AccountRepository        // Domain interface
    ) {}
}
 
// ============================================
// INFRASTRUCTURE - implements domain interfaces
// ============================================
 
// infrastructure/repositories/postgres-account-repository.ts
import { AccountRepository } from '@domain/repositories';  // ✅ Implements domain
import { Account } from '@domain/entities';               // ✅ Returns domain
import { Pool } from 'pg';                                // ✅ Infra details
 
export class PostgresAccountRepository implements AccountRepository {
    // Infrastructure implementation
}

The Import Test

Look at the imports of any service class. If a 'Domain Service' imports HTTP clients, database drivers, logging frameworks, or anything from your application layer—it's not a Domain Service. Domain Services import only from the domain layer.

Testing Implications

The distinction between Domain and Application Services has profound implications for testing—and correct separation makes testing dramatically easier.

Domain Service Testing:

Domain Services contain pure business logic with domain-only dependencies. They can be tested in isolation with no infrastructure:

domain-service-test.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Domain Service Test - Fast, isolated, no infrastructure
describe('FundsTransferService', () => {
    let service: FundsTransferService;
    let mockPolicyProvider: MockTransferPolicyProvider;
    let mockFeeCalculator: MockFeeCalculator;
    
    beforeEach(() => {
        // All dependencies are domain interfaces - easy to mock
        mockPolicyProvider = new MockTransferPolicyProvider();
        mockFeeCalculator = new MockFeeCalculator();
        service = new FundsTransferService(mockPolicyProvider, mockFeeCalculator);
    });
    
    it('should transfer funds when policy allows', () => {
        // Arrange - pure domain objects
        const source = Account.createWithBalance(Money.of(1000, 'USD'));
        const destination = Account.create();
        const amount = Money.of(100, 'USD');
        mockPolicyProvider.allowsTransfer(true);
        mockFeeCalculator.returns(Money.of(1, 'USD'));
        
        // Act - synchronous, fast
        const result = service.transfer(source, destination, amount);
        
        // Assert - straightforward domain assertions
        expect(result.status).toBe(TransferStatus.COMPLETED);
        expect(source.balance).toEqual(Money.of(899, 'USD'));  // 1000 - 100 - 1 fee
        expect(destination.balance).toEqual(Money.of(100, 'USD'));
    });
    
    it('should reject transfer when insufficient funds', () => {
        const source = Account.createWithBalance(Money.of(50, 'USD'));
        const destination = Account.create();
        
        expect(() => {
            service.transfer(source, destination, Money.of(100, 'USD'));
        }).toThrow(InsufficientFundsError);
    });
    
    it('should reject transfer when policy forbids', () => {
        mockPolicyProvider.allowsTransfer(false, 'Daily limit exceeded');
        
        expect(() => {
            service.transfer(source, destination, amount);
        }).toThrow(TransferPolicyViolationError);
    });
});

Application Service Testing:

Application Services require mocking more infrastructure concerns, but they test the orchestration logic:

app-service-test.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Application Service Test - Tests orchestration
describe('TransferApplicationService', () => {
    let appService: TransferApplicationService;
    let mockDomainService: MockFundsTransferService;  // Domain service mocked
    let mockAccountRepo: MockAccountRepository;
    let mockAuthService: MockAuthorizationService;
    let mockEventBus: MockEventBus;
    
    beforeEach(() => {
        mockDomainService = new MockFundsTransferService();
        mockAccountRepo = new MockAccountRepository();
        mockAuthService = new MockAuthorizationService();
        mockEventBus = new MockEventBus();
        
        appService = new TransferApplicationService(
            mockAccountRepo,
            mockDomainService,
            mockAuthService,
            mockEventBus
        );
    });
    
    it('should check authorization before transfer', async () => {
        mockAuthService.forbids('transfer');
        
        await expect(appService.executeTransfer('A', 'B', 100, 'USD'))
            .rejects.toThrow(UnauthorizedError);
        
        expect(mockDomainService.wasNotCalled()).toBe(true);
    });
    
    it('should orchestrate transfer correctly', async () => {
        const mockResult = new TransferResult(/* ... */);
        mockDomainService.returns(mockResult);
        
        const result = await appService.executeTransfer('A', 'B', 100, 'USD');
        
        // Verify orchestration
        expect(mockAuthService.wasCalledWith('transfer', 'A')).toBe(true);
        expect(mockAccountRepo.findById.wasCalledWith('A')).toBe(true);
        expect(mockAccountRepo.findById.wasCalledWith('B')).toBe(true);
        expect(mockDomainService.transfer.wasCalled()).toBe(true);
        expect(mockAccountRepo.save.callCount).toBe(2);  // Both accounts saved
        expect(mockEventBus.publish.wasCalledWith(
            expect.any(TransferCompletedEvent)
        )).toBe(true);
    });
});

Testing Comparison
Aspect	Domain Service Tests	Application Service Tests
Speed	Very fast (milliseconds)	Fast (may have some async)
Dependencies mocked	Domain interfaces only	Domain services + infrastructure
What's tested	Business logic correctness	Orchestration correctness
Test isolation	Completely isolated	May need test doubles
Database needed?	Never	No (mocked)
Focus	Domain rules work correctly	Use case flow is correct

Test Pyramid Alignment

This separation naturally aligns with the test pyramid: many fast Domain Service unit tests at the base, fewer Application Service integration tests in the middle, and few end-to-end tests at the top. If your domain logic is tangled with application concerns, you can't achieve this pyramid.

Summary: Domain vs Application Services

We've drawn the critical line between Domain Services and Application Services—a distinction that determines architectural cleanliness and testability.

Key Takeaways

•Different questions answered — Domain Services: 'How does the business work?' Application Services: 'How does the application coordinate work?'
•Business logic in Domain only — Don't leak domain rules into Application Services. They belong with domain objects.
•Application Services orchestrate — They coordinate use cases, manage transactions, handle authorization, and delegate to domain.
•Dependencies reveal type — Domain Services depend only on domain. Application Services bridge domain and infrastructure.
•Clean imports — Use the import test: Domain Service files should never import infrastructure or application layer code.
•Testing benefits — Correct separation enables fast, isolated domain tests and focused integration tests for applications.

What's next:

With the Domain vs Application Service distinction clear, we can now focus on best practices for designing Domain Services themselves. The next page provides practical design guidelines—naming conventions, interface design, implementation patterns, and common pitfalls to avoid.

Page Complete

You can now distinguish Domain Services from Application Services and place logic in the correct layer. Next, we'll explore practical design guidelines for building well-structured Domain Services.

3 / 4

Loading learning content...

System Design (LLD)Domain Services

Domain Services in Domain-Driven Design

LevelAdvanced

Duration55 mins

TopicDomain Services

3 / 4

Domain Service vs Application Service

The Most Common DDD Confusion

This page will make the distinction crystal clear, with concrete examples and decision frameworks you can apply immediately.

What You Will Learn

The Fundamental Distinction

At its core, the distinction is about what the service cares about:

Domain Service: Encapsulates business logic and domain rules that don't belong to a single entity. It knows domain concepts and enforces domain invariants.

Application Service: Orchestrates the use of domain objects to fulfill application use cases. It knows application workflow but delegates business rules to the domain.

Think of it this way: A Domain Service answers the question "How does the business work?" An Application Service answers the question "How does the application coordinate work?"

Domain Service

•Contains business logic
•Encapsulates domain rules
•Operates on domain objects
•Part of the domain model
•Has no knowledge of:
•• HTTP/REST/GraphQL
•• Transactions (explicit)
•• Authorization/Authentication
•• Logging infrastructure
•• External service protocols

Application Service

•Contains orchestration logic
•Coordinates use case workflow
•Uses domain objects (doesn't contain logic about them)
•Part of the application layer
•Responsible for:
•• Transaction boundaries
•• Authorization checks
•• Input validation (format, not business)
•• DTO conversion
•• Cross-cutting concerns

The 'Would Domain Experts Care?' Test

A Concrete Example: Money Transfer

Let's trace a complete money transfer use case through both service types to see how responsibilities divide:

Scenario: A REST API receives a request to transfer $100 from account A to account B.

transfer-architecture.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
// ============================================
// Controller (Infrastructure Layer)
// ============================================
@Controller('/transfers')
class TransferController {
    constructor(private transferAppService: TransferApplicationService) {}
    
    @Post()
    async createTransfer(@Body() dto: CreateTransferDto): Promise<TransferResponseDto> {
        // Controller only handles HTTP concerns
        const result = await this.transferAppService.executeTransfer(
            dto.sourceAccountId,
            dto.destinationAccountId,
            dto.amount,
            dto.currency
        );
        return TransferResponseDto.fromDomain(result);
    }
}
 
// ============================================
// Application Service (Application Layer)
// ============================================
@Injectable()
class TransferApplicationService {
    constructor(
        private accountRepository: AccountRepository,
        private fundsTransferService: FundsTransferService,  // Domain Service
        private unitOfWork: UnitOfWork,
        private authorizationService: AuthorizationService,
        private eventBus: EventBus
    ) {}
    
    @Transactional()  // Transaction boundary - Application responsibility
    async executeTransfer(
        sourceId: string,
        destId: string,
        amount: number,
        currency: string
    ): Promise<TransferResult> {
        // 1. Authorization - Application concern
        await this.authorizationService.ensureCanTransfer(
            this.currentUser,
            sourceId
        );
        
        // 2. Load domain objects
        const source = await this.accountRepository.findById(new AccountId(sourceId));
        const destination = await this.accountRepository.findById(new AccountId(destId));
        
        if (!source || !destination) {
            throw new AccountNotFoundError();
        }
        
        // 3. Create domain value object
        const money = Money.of(amount, Currency.from(currency));
        
        // 4. DELEGATE to Domain Service for business logic
        const result = this.fundsTransferService.transfer(source, destination, money);
        
        // 5. Persist changes
        await this.accountRepository.save(source);
        await this.accountRepository.save(destination);
        
        // 6. Publish integration events - Application concern
        await this.eventBus.publish(new TransferCompletedEvent(result));
        
        return result;
    }
}

domain-service.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// ============================================
// Domain Service (Domain Layer)
// ============================================
 
// Interface defined in domain layer
interface FundsTransferService {
    transfer(source: Account, destination: Account, amount: Money): TransferResult;
}
 
// Implementation - pure domain logic
class FundsTransferServiceImpl implements FundsTransferService {
    constructor(
        private transferPolicy: TransferPolicyProvider,
        private feeCalculator: TransferFeeCalculator  // Another domain service
    ) {}
    
    transfer(source: Account, destination: Account, amount: Money): TransferResult {
        // ALL business rules live here in the domain
        
        // 1. Check transfer policy (domain rule)
        const policy = this.transferPolicy.getPolicyFor(source, destination);
        if (!policy.allowsTransfer(amount)) {
            throw new TransferPolicyViolationError(policy.reason);
        }
        
        // 2. Check source account constraints (domain rule)
        if (!source.canWithdraw(amount)) {
            throw new InsufficientFundsError(source.id, amount);
        }
        
        // 3. Check destination account constraints (domain rule)
        if (!destination.canReceive(amount)) {
            throw new AccountCannotReceiveError(destination.id, amount);
        }
        
        // 4. Calculate fees (domain calculation)
        const fees = this.feeCalculator.calculateFees(source, destination, amount);
        
        // 5. Execute the domain operation
        source.withdraw(amount.add(fees));
        destination.credit(amount);
        
        // 6. Return domain result
        return new TransferResult(
            TransferId.generate(),
            source.id,
            destination.id,
            amount,
            fees,
            TransferStatus.COMPLETED
        );
    }
}

Notice the clean separation:

Application Service handles: Authorization, transaction boundaries, repository calls, DTO conversion, event publishing
Domain Service handles: Business rules, domain invariants, fee calculations, the actual transfer logic

The Application Service uses the Domain Service but doesn't replicate its logic. The Domain Service knows nothing about HTTP, transactions, or event buses.

Common Mistakes and How to Fix Them

Let's examine the most common mistakes developers make when distinguishing these service types.

Mistake 1: Putting Business Logic in Application Services

This is the most common error—and it leads directly to the Anemic Domain Model anti-pattern:

mistake-1.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// ❌ WRONG: Business logic in Application Service
class OrderApplicationService {
    async placeOrder(dto: PlaceOrderDto): Promise<OrderDto> {
        // Authorization - OK, this belongs here
        await this.authService.ensureCanPlaceOrder(this.currentUser);
        
        // Business logic - WRONG, should be in domain
        if (dto.items.length === 0) {
            throw new Error("Order must have items");  // Domain rule leaked!
        }
        
        // More business logic - WRONG
        let total = 0;
        for (const item of dto.items) {
            const product = await this.productRepo.findById(item.productId);
            if (product.stock < item.quantity) {
                throw new Error("Insufficient stock");  // Domain rule leaked!
            }
            total += product.price * item.quantity;
        }
        
        // Discount logic - WRONG
        if (total > 100) {
            total = total * 0.9;  // Domain rule leaked!
        }
        
        // ... save order ...
    }
}
 
// ✅ CORRECT: Domain logic in Domain layer
class OrderApplicationService {
    async placeOrder(dto: PlaceOrderDto): Promise<OrderDto> {
        await this.authService.ensureCanPlaceOrder(this.currentUser);
        
        // Create domain objects
        const order = Order.create(this.currentUser.customerId);
        for (const item of dto.items) {
            const product = await this.productRepo.findById(item.productId);
            order.addItem(product, item.quantity);  // Domain validates internally
        }
        
        // Let domain service handle business logic
        this.orderPricingService.applyPricing(order);  // Domain service
        await this.inventoryService.reserveForOrder(order);  // Domain service
        
        await this.orderRepo.save(order);
        return OrderDto.from(order);
    }
}

Mistake 2: Making Domain Services Depend on Infrastructure

Domain Services should be pure domain. When they know about frameworks, databases, or external services, they become tangled with infrastructure:

mistake-2.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// ❌ WRONG: Domain Service with infrastructure dependencies
class PricingDomainService {
    constructor(
        private httpClient: HttpClient,      // ❌ Infrastructure!
        private database: Database,          // ❌ Infrastructure!
        private logger: Logger              // ❌ Infrastructure!
    ) {}
    
    async calculatePrice(order: Order): Promise<Money> {
        this.logger.info("Calculating price...");  // ❌ Infrastructure concern
        
        // Direct database access from domain
        const rates = await this.database.query(
            'SELECT * FROM tax_rates WHERE region = ?',
            [order.region]
        );  // ❌ SQL in domain!
        
        // HTTP call from domain
        const exchangeRate = await this.httpClient.get(
            'https://api.exchange.com/rate'
        );  // ❌ HTTP in domain!
        
        // calculation...
    }
}
 
// ✅ CORRECT: Domain Service with domain abstractions
interface TaxRateProvider {
    getRatesFor(region: Region): TaxRate[];
}
 
interface ExchangeRateProvider {
    getRate(from: Currency, to: Currency): ExchangeRate;
}
 
class PricingDomainService {
    constructor(
        private taxRateProvider: TaxRateProvider,     // Domain interface
        private exchangeProvider: ExchangeRateProvider // Domain interface
    ) {}
    
    calculatePrice(order: Order): Money {
        const rates = this.taxRateProvider.getRatesFor(order.region);
        const rate = this.exchangeProvider.getRate(order.currency, baseCurrency);
        
        // Pure domain calculation using domain abstractions
        return this.computePrice(order, rates, rate);
    }
}

Mistake 3: Using Domain Services for CRUD Operations

Simple create, read, update, delete operations don't need Domain Services:

mistake-3.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// ❌ WRONG: Domain Service for simple CRUD
class CustomerDomainService {
    createCustomer(name: string, email: string): Customer {
        return new Customer(name, email);  // This is just construction
    }
    
    updateCustomerEmail(customer: Customer, email: string): void {
        customer.email = email;  // This should be a method ON Customer
    }
}
 
// ✅ CORRECT: Entity handles its own simple operations
class Customer {
    constructor(
        private name: CustomerName,
        private email: EmailAddress
    ) {}
    
    changeEmail(newEmail: EmailAddress): void {
        this.email = newEmail;
        // Possibly raise CustomerEmailChanged event
    }
}
 
// Application Service for the use case
class CustomerApplicationService {
    async changeEmail(customerId: string, newEmail: string): Promise<void> {
        const customer = await this.customerRepo.findById(customerId);
        customer.changeEmail(new EmailAddress(newEmail));
        await this.customerRepo.save(customer);
    }
}

The 'Service' Suffix Trap

The Layer Test: Where Does This Service Belong?

Here's a systematic decision framework for placing services correctly. For each potential service, ask these questions in order:

Service Placement Decision Framework

•Does this logic belong to a single entity? → If yes, put it IN that entity. Not a service at all.
•Is this purely about application workflow? (transactions, authorization, DTO mapping, coordinating calls) → Application Service
•Is this business logic involving multiple domain objects? → Domain Service
•Does this require infrastructure access but no domain logic? → Infrastructure Service
•Does this implement a domain interface using infrastructure? → Infrastructure implementation of Domain Service interface

Quick Reference: Where Does This Logic Go?
Type of Logic	Where It Goes	Example
Single entity's behavior	Entity method	order.cancel(), customer.changeAddress()
Use case orchestration	Application Service	PlaceOrderAppService, CheckoutAppService
Transaction management	Application Service	@Transactional decorator or explicit UoW
Authorization	Application Service	Before calling domain logic
Business calculation across objects	Domain Service	PricingService, MatchingService
Domain rules spanning aggregates	Domain Service	FundsTransferService
External API integration	Infrastructure Service	ExternalPaymentGateway implementation
Database access	Repository implementation	PostgresOrderRepository

placement-examples.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
// Complete layer separation example
 
// DOMAIN LAYER -----------------------------
// 1. Entity with its own logic
class Order {
    private items: OrderItem[];
    private status: OrderStatus;
    
    addItem(product: Product, qty: Quantity): void { /* entity logic */ }
    cancel(): void { /* entity logic */ }
    calculateSubtotal(): Money { /* entity can calculate from own data */ }
}
 
// 2. Domain Service for cross-entity logic
interface ShippingCostCalculator {
    calculate(order: Order, destination: Address, carrier: Carrier): Money;
}
 
// 3. Domain Service for complex business rules
interface InventoryAllocationService {
    allocateInventory(order: Order): AllocationResult;
}
 
// APPLICATION LAYER ------------------------
class PlaceOrderApplicationService {
    constructor(
        private orderRepo: OrderRepository,
        private inventoryService: InventoryAllocationService,  // Domain
        private shippingCalculator: ShippingCostCalculator,    // Domain
        private paymentGateway: PaymentGateway,                // Infra interface
        private emailSender: EmailSender                       // Infra interface
    ) {}
    
    @Transactional()  // ← Application concern
    @Authorized(['place-order'])  // ← Application concern
    async placeOrder(dto: PlaceOrderDto): Promise<OrderDto> {
        // Orchestration, not business logic
        const order = Order.create(dto.customerId);
        
        for (const item of dto.items) {
            order.addItem(/* ... */);
        }
        
        // Delegate to domain services
        const allocation = await this.inventoryService.allocateInventory(order);
        const shipping = this.shippingCalculator.calculate(
            order, dto.destination, dto.carrier
        );
        
        // Delegate to infrastructure
        await this.paymentGateway.charge(order.total());
        
        await this.orderRepo.save(order);
        await this.emailSender.sendOrderConfirmation(order);  // Infra
        
        return OrderDto.from(order);
    }
}
 
// INFRASTRUCTURE LAYER ---------------------
// Implements domain interface with infrastructure
class StripePaymentGateway implements PaymentGateway {
    async charge(amount: Money): Promise<PaymentResult> {
        // Stripe API calls - pure infrastructure
    }
}

The Dependency Direction

Understanding the difference between Domain and Application Services is easier when you visualize the dependency direction in a layered architecture:

The Dependency Rule: Higher-level layers depend on lower-level layers. The domain layer depends on nothing external (it's the core).

[ Controllers / UI ]      →  HTTP, views, CLI
        ↓
[ Application Services ]  →  Use cases, orchestration, transactions
        ↓
[ Domain Services ]       →  Business logic, domain operations
        ↓
[ Entities / VOs ]        →  Core domain concepts, business rules
        ↓
[ Domain Interfaces ]     →  Contracts for infrastructure
        ↑
[ Infrastructure ]        →  DB, APIs, files (IMPLEMENTS domain interfaces)

Key Relationship Rules

•Application Services CALL Domain Services — Application uses domain to fulfill use cases
•Domain Services use Domain objects — Entities, value objects, domain interfaces only
•Domain layer NEVER imports from Application — Domain is pure, knows nothing about use cases
•Infrastructure IMPLEMENTS Domain interfaces — Dependency inversion in action
•Application coordinates Infrastructure and Domain — It's the glue between them

imports-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// ============================================
// DOMAIN LAYER - knows ONLY domain
// ============================================
 
// domain/services/funds-transfer-service.ts
import { Account } from '../entities/account';
import { Money } from '../value-objects/money';
import { TransferPolicy } from '../policies/transfer-policy';
// ❌ NEVER: import { TransferAppService } from '@app/services';
// ❌ NEVER: import { Database } from 'typeorm';
// ❌ NEVER: import { HttpClient } from '@nestjs/common';
 
export class FundsTransferService {
    // Pure domain implementation
}
 
// ============================================
// APPLICATION LAYER - coordinates all
// ============================================
 
// application/services/transfer-app-service.ts
import { FundsTransferService } from '@domain/services';  // ✅ Uses domain
import { AccountRepository } from '@domain/repositories';  // ✅ Domain interface
import { TransferResult } from '@domain/results';         // ✅ Domain type
import { TransferDto } from '../dtos/transfer-dto';       // ✅ App layer DTO
import { Transactional } from '@infrastructure/decorators'; // ✅ Uses infra
 
export class TransferApplicationService {
    constructor(
        private domainService: FundsTransferService,  // Domain dependency
        private accountRepo: AccountRepository        // Domain interface
    ) {}
}
 
// ============================================
// INFRASTRUCTURE - implements domain interfaces
// ============================================
 
// infrastructure/repositories/postgres-account-repository.ts
import { AccountRepository } from '@domain/repositories';  // ✅ Implements domain
import { Account } from '@domain/entities';               // ✅ Returns domain
import { Pool } from 'pg';                                // ✅ Infra details
 
export class PostgresAccountRepository implements AccountRepository {
    // Infrastructure implementation
}

The Import Test

Testing Implications

The distinction between Domain and Application Services has profound implications for testing—and correct separation makes testing dramatically easier.

Domain Service Testing:

Domain Services contain pure business logic with domain-only dependencies. They can be tested in isolation with no infrastructure:

domain-service-test.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Domain Service Test - Fast, isolated, no infrastructure
describe('FundsTransferService', () => {
    let service: FundsTransferService;
    let mockPolicyProvider: MockTransferPolicyProvider;
    let mockFeeCalculator: MockFeeCalculator;
    
    beforeEach(() => {
        // All dependencies are domain interfaces - easy to mock
        mockPolicyProvider = new MockTransferPolicyProvider();
        mockFeeCalculator = new MockFeeCalculator();
        service = new FundsTransferService(mockPolicyProvider, mockFeeCalculator);
    });
    
    it('should transfer funds when policy allows', () => {
        // Arrange - pure domain objects
        const source = Account.createWithBalance(Money.of(1000, 'USD'));
        const destination = Account.create();
        const amount = Money.of(100, 'USD');
        mockPolicyProvider.allowsTransfer(true);
        mockFeeCalculator.returns(Money.of(1, 'USD'));
        
        // Act - synchronous, fast
        const result = service.transfer(source, destination, amount);
        
        // Assert - straightforward domain assertions
        expect(result.status).toBe(TransferStatus.COMPLETED);
        expect(source.balance).toEqual(Money.of(899, 'USD'));  // 1000 - 100 - 1 fee
        expect(destination.balance).toEqual(Money.of(100, 'USD'));
    });
    
    it('should reject transfer when insufficient funds', () => {
        const source = Account.createWithBalance(Money.of(50, 'USD'));
        const destination = Account.create();
        
        expect(() => {
            service.transfer(source, destination, Money.of(100, 'USD'));
        }).toThrow(InsufficientFundsError);
    });
    
    it('should reject transfer when policy forbids', () => {
        mockPolicyProvider.allowsTransfer(false, 'Daily limit exceeded');
        
        expect(() => {
            service.transfer(source, destination, amount);
        }).toThrow(TransferPolicyViolationError);
    });
});

Application Service Testing:

Application Services require mocking more infrastructure concerns, but they test the orchestration logic:

app-service-test.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Application Service Test - Tests orchestration
describe('TransferApplicationService', () => {
    let appService: TransferApplicationService;
    let mockDomainService: MockFundsTransferService;  // Domain service mocked
    let mockAccountRepo: MockAccountRepository;
    let mockAuthService: MockAuthorizationService;
    let mockEventBus: MockEventBus;
    
    beforeEach(() => {
        mockDomainService = new MockFundsTransferService();
        mockAccountRepo = new MockAccountRepository();
        mockAuthService = new MockAuthorizationService();
        mockEventBus = new MockEventBus();
        
        appService = new TransferApplicationService(
            mockAccountRepo,
            mockDomainService,
            mockAuthService,
            mockEventBus
        );
    });
    
    it('should check authorization before transfer', async () => {
        mockAuthService.forbids('transfer');
        
        await expect(appService.executeTransfer('A', 'B', 100, 'USD'))
            .rejects.toThrow(UnauthorizedError);
        
        expect(mockDomainService.wasNotCalled()).toBe(true);
    });
    
    it('should orchestrate transfer correctly', async () => {
        const mockResult = new TransferResult(/* ... */);
        mockDomainService.returns(mockResult);
        
        const result = await appService.executeTransfer('A', 'B', 100, 'USD');
        
        // Verify orchestration
        expect(mockAuthService.wasCalledWith('transfer', 'A')).toBe(true);
        expect(mockAccountRepo.findById.wasCalledWith('A')).toBe(true);
        expect(mockAccountRepo.findById.wasCalledWith('B')).toBe(true);
        expect(mockDomainService.transfer.wasCalled()).toBe(true);
        expect(mockAccountRepo.save.callCount).toBe(2);  // Both accounts saved
        expect(mockEventBus.publish.wasCalledWith(
            expect.any(TransferCompletedEvent)
        )).toBe(true);
    });
});

Testing Comparison
Aspect	Domain Service Tests	Application Service Tests
Speed	Very fast (milliseconds)	Fast (may have some async)
Dependencies mocked	Domain interfaces only	Domain services + infrastructure
What's tested	Business logic correctness	Orchestration correctness
Test isolation	Completely isolated	May need test doubles
Database needed?	Never	No (mocked)
Focus	Domain rules work correctly	Use case flow is correct

Test Pyramid Alignment

Summary: Domain vs Application Services

We've drawn the critical line between Domain Services and Application Services—a distinction that determines architectural cleanliness and testability.

Key Takeaways

•Different questions answered — Domain Services: 'How does the business work?' Application Services: 'How does the application coordinate work?'
•Business logic in Domain only — Don't leak domain rules into Application Services. They belong with domain objects.
•Application Services orchestrate — They coordinate use cases, manage transactions, handle authorization, and delegate to domain.
•Dependencies reveal type — Domain Services depend only on domain. Application Services bridge domain and infrastructure.
•Clean imports — Use the import test: Domain Service files should never import infrastructure or application layer code.
•Testing benefits — Correct separation enables fast, isolated domain tests and focused integration tests for applications.

What's next:

Page Complete

You can now distinguish Domain Services from Application Services and place logic in the correct layer. Next, we'll explore practical design guidelines for building well-structured Domain Services.

3 / 4