Clarification on the Practical Usage of Domain Services in DDD

[vietlait]

As I delve into Domain-Driven Design, I've encountered Domain Services as a way to encapsulate domain logic that doesn't naturally fit within a single entity. However, I'm finding it challenging to identify scenarios where Domain Services should be used instead of other DDD concepts such as Domain Entities or Value Objects. The existing code samples and documentation I've come across do not provide clear and practical use cases that would help me better understand the concept.

I kindly request the community's assistance in shedding light on the following points:

• Real-world scenarios where Domain Services are a suitable and beneficial choice.
• Examples of domain logic that naturally belong to Domain Services rather than other DDD elements.
• Clear and concise code samples that demonstrate the implementation of Domain Services in practical contexts.
• Best practices and guidelines for designing and utilizing Domain Services effectively.

I believe that having concrete examples and discussions around Domain Services will greatly enhance my understanding of this crucial aspect of Domain-Driven Design. Your insights and contributions would be invaluable in helping me and others grasp this concept more comprehensively.

Thank you for your time and assistance.

[Sairyss]

Domain Services are less frequently used than other DDD elements, that's why you don't see many examples online.
Also people tend to use Application Services for logic that is technically a Domain Service without realizing it.

I see it like this: imagine you have two (or more) entities, and you need to implement some new use case that involves both of those entities. You can't put this logic in one of them, because it will make them coupled. Here where Domain Services come into play, they will orchestrate those entities.

Examples:

Imagine that you are making an online shop and have an Order entity that encapsulates all the logic related to the orders, like createOrder and cancelOrder, etc. And you also have a Customer entity for your customers.

Now lets say you have a new requirement: when placing an order, if your customer matches some conditions, for example he has a VIP status and has been a customer for more than 3 years, his Order will have a 10% discount.

A domain service can look like this:

export class OrderDomainService {
  applyDiscountsIfEligible(order: Order, customer: Customer) {
    if (customer.isVIP() && customer.isOlderThanYears(3)) {
      order.applyDiscount(10);
    }
    return order;
  }
}

This way you don't have to mix customers and orders into a single Entity, but orchestrate them using a Domain Service.

There is no one rule fits all here, everything depends on the business logic that you are implementing.

[vietlait]

Thank you for your response.

Based on the example you provided, it seems I have a basic understanding of Domain Services. I'm considering placing the OrderDomainService in the directory structure as follows: src/modules/order/domain/services/order.domain-service.ts.

In this scenario, my application service would look something like this:

create-order.service.ts

export class CreateOrderService implements ICommandHandler {
  constructor(private readonly orderRepository: OrderRepository) {}

  async handle(command: SignUpCommand): Promise<Result<OrderEntity, Error>> {
    let order = OrderEntity.create(command);
    // How to get CustomerEntity?
    const orderService = new OrderDomainService();
    order = orderService.applyDiscountsIfEligible(order, customer);
    const created = await this.orderRepository.persist(order);
    return Ok(created);
  }
}

I would like to know if my example code is reasonable, and if injecting customer.repository.ts into the constructor of CreateOrderService is the right approach to obtain CustomerEntity.

Thank you for your guidance.

[Sairyss]

constructor(private readonly orderRepository: OrderRepository) {}

Better to use a port here OrderRepositoryPort, and then you inject the implementation

let order = OrderEntity.create(command);

use const, no need to reassign it below. if you apply the discount your order can mutate the object internally using this.discount = newDiscount

const orderService = new OrderDomainService();

You have to inject OrderDomainService in the constructor

injecting customer.repository.ts into the constructor of CreateOrderService is the right approach to obtain CustomerEntity

Yes, you can inject the repository

I would do it like this:

export class CreateOrderService implements ICommandHandler {
  constructor(
    private readonly orderRepository: OrderRepositoryPort, 
    private readonly customerRepository: CustomerRepositoryPort, 
    private readonly orderService: OrderService,
  ) {}

  async handle(command: SignUpCommand): Promise<Result<OrderEntity, Error>> {
    const order = OrderEntity.create(command);
    const customer = this.customerRepository.findById(command.customerId);
    orderService.applyDiscountsIfEligible(order, customer);
    const created = await this.orderRepository.persist(order);
    return Ok(created);
  }
}

[vietlait]

Thank you so much for sharing the information.
It's truly valuable for newcomers to DDD like me.
In the future, if you could provide more of your own code examples to further illustrate the concepts or various use cases, that would be fantastic.
I still have many questions and will ask more in the future.
Wishing you a wonderful day ahead!