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)