Generally speaking, there could be a hierarchy of domain objects, which are controlled by the services. If these domain objects are only data placeholders, with no behavior, then this is not true to object-oriented programming.
What we have here is what Martin Fowler would call the Anemic Domain Model.
More commonly, within OOP, a group of domain objects have behavior whose interactions form business logic. This logic, in turn, is encapsulated by the Service.
Such services are stateful, with their state being comprised of these domain objects.
Services may also be stateless and offer self-sufficient functionality.
Imagine, if you will, a very simple calculator API.
An HTTP request was sent your application, which the uses the API in data extraction, some complex calculation, and, at the end, an HTTP response containing the computed data as a SOAP/REST/etc. message from this endpoint.
Once the response is received, this should then be returned to the client that sent the original request.
You don't want to force your client to manually invoke the computation and transformation of the input. Instead, you want to simply offer them a service API which encapsulates this logic and returns to them the expected result.
For Spring applications, you have the Spring annotation @Service.
