Multiple Interfaces

I recently had a vision about how to combat the abuse of the
pesky-but-needed getters and setters that are necessary for domain
objects that live in a real system and that have to be stored,
displayed, and sometimes created by external factories.

Anyway, since the getters and setters will end up being there anyway,
alongside your actual business logic methods, would it be better to
have the domain object implement multiple interfaces, one for each
layer of the system that has to see assorted getters and setters?

Here is what I'm talking about:

// for use with other domain objects; exposes meaningful business
logic methods only
        public interface Customer
        {
// our lone business logic method
            void describe(CustomerDescription description);
        }

// to be used when displaying a customer in UI and capturing a new one
from the user; TO stands for Transfer Object
        public interface CustomerTO
        {
            String getFullName();
            String getAddress();
            void setFullName(String name);
            void setAddress(String addr);
        }

// to be used in the data access layer when storing and loading from
persistence; DO stands for Data Object

        public interface CustomerDO
        {
            String getFirstName();
            String getLastName();
            long getID();
            String getAddress();

            void setFirstName(String str);
            void setLastName(String str);
            void setID(long ID);
            void setAddress(String str);
        }

Then in the domain layer, have a CustomerImpl implement all three.

So far, here is my analysis of this approach:

Good:
* no unnecessary accessors pollute the interface that is exposed to
the domain layer
* one implementation instead of a TO implementation and DO
implementation, plus the actual domain object
* factories to convert to and from each interface are simple exercises
in casting

Bad:
* one implementation instead of a TO implementation and DO
implementation -- this might be viewed as polluting the expressive
domain object
* factories to convert to and from each interface are simple exercises
in casting -- casting considered harmful
* CustomerImpl still has public getters and setters; nothing stops
someone in the domain layer from peeking and casting from Customer to
CustomerImpl and defeating the entire purpose
* an instance of CustomerImpl is shared throughout UI, App, Domain,
and Data Access; this might not be a scalable option

Has anyone tried this? Are there any pros or cons that I missed? Is
this approach practically any better than having a TO, DO, and actual
domain object separated, and then converting (via instantiation
instead of casting) between each class?

------------------------------------