Mohamed's right about adding methods like data access to the domain objects. But what about domain logic? That's a more philosophical question. Classical Object-Oriented methods would put most of the domain logic in the domain objects. But Service Oriented approaches tend to avoid that - they use what I've heard call an "anaemic domain model", where you restrict domain objects to the basics and have all the domain logic provided by your services. Both are valid approaches.
It's also a bit of a philosophical question as to whether you expose the domain objects. In a layered architecture you just need to make sure that all dependencies go downwards - lower layers don't call upper layers. But there's also the concept of a
strict layered architecture, where each layer is supposed to depend
only on the layer immediately below. It gives you the advantage of reduced coupling (so if you want to replace a layer you only have to consider the one above) at the cost of more infrastructure. I would suggest that
updating the domain objects should be forced to go through the service layer, though.
So "it depends"
.