DAOs vs Repositories...

DAO = Repository
BO (Business Object) = Service
Bean = DTO != Domain Object

So the "Repository/Service" pattern roughly equals the "DAO/BO" pattern in my mind, just different nomenclature.

They imply layers of responsbility; but what those responsibilities are often comes down to personal style. E.g. I've seen the @Transaction decoration placed on the service (as some would argue transactions are a business concern) however I've also seen then defined in DAOs.

DTOs/Beans naturally tend toward placement in higher layers, e.g. an MVC controller* or a JSF view deals with these data bag abstractions, although the "bean" in JSF takes on some controller responsibilities vis-a-vis interacting with the BOs, indeed I've seen beans be called controllers in JSF.

BOs/Services may have the responsibility of translating the beans to domain objects and passing them to corresonding CRUD operations of the DAOs/Repositories; although I've seen where it's been convenient to pass domain objects (which DAOs/Repositories typically deal with at the persistence layer) all the way to the front-end. Likewise, I've also seen beans be passed from front-end to BO to DAO where convenient.

So while the assignment of responsibility among the layers isn't always straightforward, having responsibilities spread out, ala SRP, is useful so that one layer doesn't try to do too much.

* In Spring MVC the controller may set a "form backing bean" as a "model attribute" because it's through the model context that the view and the controller communicate.