Refactor classes to be domain clean

The beauty of object oriented programming is that you can have a program that resembles the real world objects that it is to represent. Domain driven design is the notion that you create models based on a "domain". That is a subject area. This can be fuzzy, or it can be industry agreed upon. The catch is that you are writing an application, and not a domain model. What does that mean? It means that you will be tempted to add fields to your classes that meet your application's needs, but are not really part of your domain.
Transcendental Beans is here to save you from polluting your domain model with application schemata. You have the power of AspectJ introduction to separate application schema from domain schema.
Try aspect refactoring with AspectJ on your persistent classes with Transcendental Beans

Is-a vs. has-a

When you model your system in object oriented methodologies, you have to choose whether a class "is-a" a certain type or if it "has-a" a certain type. Is this confusing? The best way to think of this is to ask what is a customer? If you have a class "Person" in your model, then you might think that a "Customer" is-a "Person". But that starts to get complicated. A customer is someone who has bought a certain product. So, can you scale the is-a version of customer to purchasing of multiple products? Maybe you can model a customer as an order that has been fulfilled, and a person can have a collection of orders, thus a person "has-a" collection of orders. But many situations involving two different products do not occur at the same time usually, so you would preferr to just treat the person as a customer while in the situation involving a certain product.
Then you could have the best of both worlds. But what system or languatge can handle this? You would always have to have some sort of layering and pretend that the other stuff doesn't matter while on the boundaries of the layer. What if there was a DBMS that could let you define both simple versions of person and customer, and the DBMS would integrate the various views as real objects?
An AODBMS would be able to define various dimensions of the same entity and provide a way for the simplified dimensional slice to integrate the various views into a single database entity.