Disclaimer - Well hard to answer without seeing any proper details what to modify and how much to modify ,number of users supported any bandwidth constrains on the client systems etc. but here you go.
"Is it better to save the data in the xml or json files?"
Consider memory foot print,multilingual support,expected response time etc.
Pros of both of them you can store data in any DB later on.
They(XML/JSON) are best fit for sharing data between systems and not for storing data
"As in the system needs to save history of changes and it may go from one stage to another" - how much needs to be saved each field change or just the details that who accessed the form and for how much time.
How to Store Historical Data
Design part few pointers(Beware of over engineering)
- In-memory DB might help in your case(if speed is an issue due to too many fields in the form).
- Template pattern - can help you in case of Design to force a structure in application.
- Decorator Pattern - For the part where "data needs to be manipulated to certain extent."
- Strategy Pattern - if you want to separate out your modification algorithms("data needs to be manipulated to certain extent").
- Loan documents fields/parts which are kind of free length based use something as MongoDB,Casandra etc.
- Logging use AOP.
THUMB RULE - They larger the number of layers in the architecture the more refined it gets but beware of over engineering.
Concept of layering lets say in something as simple as logging - Spring + SLF4J + Logback/log4j etc.
SLF4J is your layer which let's you use any other logging framework.
Lastly it all depends upon on how far you wanna go ? -Read budget of the client.
QUICK-FIX- If the problem is writing entities then design one thing perfectly Database or Entities other part can be generated by tools :)
Happy designing till then :)
