Chapter 8 of the book talks about designing layered applications and I think the example does a nice job of showing how to abstract all the different kinds of operations into the appropriate layer.

Although I am having problems keeping my domain objects from needing access to my DAO's. For a simple example consider a User object that has an email address. Email address must be unique for each user. There are mutlple ways I can do this.

1)Check for uniqueness in the property setter. this will require the User domain object to reference the persistence API or my DAO.

2)Check for uniqueness in a validate operation on the User domain object. This also requires a reference to the persistence API or my DAO.

3)Move the uniqueness check to an Add operation on my DAO. This works good but the problem arises when my User Domain object is updated and the email address is changed. The session is either flushed or committed and now my validation check has been bypassed.

So the question is, how can I safely do this validation check without my domain object knowing about the persistence API or my DAO's?

You do it in the controller, of course.

I still don't see how this ensures the integrity of my entity. Say for example that the controller got bypassed by a layer that had access to the session. There is still the possibility for a non unique email address to make its way to the database.

Am I missing something here, or is this just one of the risks with transparent persistence?

If something bypasses this code to create a user, you have a bug in your application. The job of the database constraint on the UNAME column is going to take care of this and throw an exception if you do it wrong. Sometimes "business logic" really means just a simple constraint, and sometimes you can't enforce a relation-level constraint, such as UNIQUE, in a Java data model, because Java doesn't have relations.

Btw, the code for an update of a user looks just the same.