As we've seen, Services represent operations inside our system, and we can differentiate between three versions of them:

• Application Services: Help coordinate requests from the outside world into the Domain. These Services should not contain Domain logic. Transactions are handled in the application level; wrapping your services inside transnational decorators will make your code transaction agnostic.
• Domain Services: Operate with Domain concepts only, which are expressed by the Ubiquitous Language. Remember to postpone implementation details and think of behavior first, as abuse of Domain Services will lead to Anemic Domain Models and bad Object-Oriented Design.
• Infrastructure Services: Operate over Infrastructure, doing things like sending emails or logging information.

Our most important recommendation is that you should consider all your options before deciding on creating a Domain Service. First try to move your business logic inside an Entity or Value. Check with some workmates. Review again. If, after different approaches, the best option is creating a Domain Service, go for it.