Hello there. In the previous video, we talked about value objects. In this video, we will talk about domain services. So, let's begin. To classify services in general, there are basically three different types: Domain services, application services, and infrastructure services. Domain services encapsulate business logic that doesn't naturally fit within a domain object and are not typical CRUD; create, read, update, delete operations. Those would belong to a repository. Application services are used by external consumers to talk to your system. Think web services. If consumers need access to CRUD operations, they would be exposed here. Infrastructure services are used to abstract technical concerns such as email providers. Now let's dive a little deeper into the domain service. Domain services encapsulate domain logic and concepts that are not naturally modeled as value objects or entities in your model. Domain services have no identity or state. Their responsibility is to orchestrate business logic using entities and value objects. For example, consider a shipping cost calculator.

This service is a business function that given a set of consignments, value objects and a collection of weight bandings can calculate the cost of shipping. This functionality does not sit comfortably on a domain object. So, it's better represented as a domain service. In fact, we can think of a domain service as a domain object. This means that it is an object of your domain in the analysis-bounded context. The confusion with DDD is that everyone that is trying to understand every term pays much attention to the DDD names and forgets about the domain. DDD is doing object-oriented programming. The only difference is that DDD fixes some names for domain objects that play a given role within a domain-bounded context. For example, you're faced with a scenario where you generate an invoice for a customer's phone calls. In this case, the objects you will define can be as follows: Biller, Invoice, PhoneCall, PriceList, and PhoneCallRegistry.

As you can see, these are the domain objects defined for the user story and the names we can use to write the code. However, if we use DDD, we need to rename some of these objects to BillingService, Invoice, PhoneCall, PriceList, PhoneCallRepository. As you can see, two names changed. You can see now that a domain service is a guy performing the service for accomplishing some task. In this case, the Biller. Second, the phone call register plays the role of a collection. It is compliant with what a repository is in terms of DDD, so we renamed it to PhoneCallRepository. Domain services are stateless. If you take into account what I said in the previous point, you can see a guy that fills an invoice plays the role of a biller. The guy's just there, sitting down at his desk, doing his work, and attending to many threads. If any other guy replaces him, we do not care, we just want phone calls to be invoiced. So, that's enough for now about domain service. Let's take a short break here. In the next video, we will talk about aggregates and repositories. So, I'll see you there.