I have personnaly 2 ways of getting "as far as possible" from refactor problems :

- mostly use flat objets, ie some objets that are as DB tables (only simple POJO with foreign keys, no child objects). This way it is easy to get and store used objects (with SQL or JPA frameworks, which has some annotations to map fields with DB columns where you can set your "business translations"). And for writing rules, it could be simpler too (do the join by testing attributes, ie the attributes you want in this particular context ...)

- use automatic translation from your old code, if it is possible.... it depends on the corresponding code complexity, but then you can handle most of rules automatically (so changes in data model can be handled massively).

But I share Wolfgang's point of view when he says that building rules totally independant of underlying objects is not realistic.

You will have refactor painful work if you start too soon on a not enough stable data model. So the real way to avoid too much refactor ... is to spend time at building a stable data model ... (considering that point, rules projects are not that different from standard java projects)