Project Architecture For Enhancing Legacy project

I am working on legacy project. Now the situation demands project to be divided into parts. What strategy I should follow to do this task.

Description:

The legacy project (A) is fully functional web application with almost well defined layers. But now i need to extend the project to a further enhancement. This project usage maven as build tool. But it is used only for dependency managements only. (project exported to war form inside eclipse).

The new enhancement needs me to add new data table, new UI(jsp, css, js and images).

What should be my strategy to enhance to application.

My proposed design.

I am planing to create two new projects

Project B : Main Enhancement works will done in this project. Will have all layers like service layer, dao layer and UI layer in itself. And will be a web appl开发者_StackOverflow中文版ication in itself.

Project C : Extract some common model and service code form project-A and create this project. This project will be added as dependency to both the projects.

If my this approach is okay! Then i presume there will be problem be problem in deployment. These two projects will demand to deploy separately(currently tomcat is used). But I must deploy these two projects as one war. So, i need to have a plan to change the web.xml entries to have configurations for both projects. This will comes with some more complexities with project.

What should be my design for the project? Does my plan sounds good.

I'd keep your development as part of the same 'project' and deployment unit, otherwise you're separating when there is no real requirement or architectural need to.

However you're describing difficulties of changes for the enhancements affecting the existing code-base. For this problem I'd recommend creating a branch in your source control tool and performing your enhancement development on the branch. This allows you to fully develop and test without affecting the live codebase (which can still have bugfixes etc applied).

Once you've fully tested, you can merge the branch back to the main codebase and perform final regression testing that the full application works before releasing to live.

The general approach you've outlined is quite sensible (isolating a common service layer - project C - and building A and B on top of it). I would call that fairly routine.

I'm confused about the specific relationship between projects A and B. More precisely, why projects A and B have to be deployed separately, but be a part of the same .war...?

Which requirement demands that you spilt the projects?

If the legacy system is well structured you could just add the new code into the legacy project.

If you do need to split, you could build an "anti corruption layer" that the new system would use to talk to the functionality in the legacy system. This would then allow you to avoid making any changes at all in the legacy system.