However if you consider a simple design – and here let’s say some sort of services layer over a database – I think it’s a really fatal mistake to pollute the services layer with of JPA or Hibernate (etc) query constructions and manipulations. The service layer’s job is to marshal the service input, ask the data layer to do it’s work, and marshal the result back to the requestor. In my view it’s never bad form to do something like this;

public class ServiceLayer implements Service {
    public DataOut myService(DataIn in) {
        // unmarshal and check DataIn if neccessary
        someData someData = someDataLayer
         .findSomeDataUsingAStoredProcedureAlreadyInTheDB(in.getName());
        MoreData moreData = moreDataLayer
         .createMoreDataRelationshipUsingAFancyHSQLQueryOperations(in, someData);
        return new DataOut(someData, moreData);
    }
}

For a start, as a design, that communicates effective intention. At this level of abstraction, it isn’t really material exactly what the two data layer methods do. And when you do need to know what either methods do, you’re not forced to consider the service layer at the same time.

Obviously, I chose method names there to reflect what might be happening “under the hood” of the data layer. Which isn’t something you’d actually do in practice. But the end result is, you’ve encapsulated the access in sensibly named methods in a convenient abstraction. I don’t see the problem.

Plus, so far, I have never seen anyone actually try to do this (i.e. replace database access with something else) across their whole application. Everybody *talks* about doing it, but it (almost) never actually seems to happen in practice. So YAGNI applies.