I work for a country-wide company, so the software we develop is large scale.
Our core system is Web based including webservices. We are currently redesigning the entire project and is moment to start the project structure.
We have like 7 web modules including for the web project based on Struts2 and Spring 3.1. A Webservice core based on JAX-WS and Spring 3.1
My question is what are the best practices to design the project structure and modularization for a project like this:
We’ll definitely use Maven and OSGi if needed. I’m thinking in something like
WebProject.war
|---Web.xml
|--- Libs
|
|--- Web Module1.jar
|--- Web Module2.jar
|--- Web Module3.jar
|--- Web Module4.jar
|--- Web Module5.jar
|--- Web Module6.jar
WebService.war
|---Web.xml
|--- Libs
|
|--- Service.jar
|--- Service2.jar
EJBProject.jar
|
|--- module.jar
|--- module2.jar
This is what I personally have in mind, but we are looking for something better modularized so we can work and deploy WebModule1.jar without affecting the other modules and main project WebProject.war. Also with this we want the specialized teams to only have the code of their projects, so if a Team must work only with Service2.jar in their IDE they will only have the code for Service2.jar and a resource project with the others project already compiled.
Thanks
The key aspect of modularity is that your module knows as little as is humanly possible so that it can be reused in many different contexts. Bugs only occur when an assumption is violated, minimizing the assumptions is the biggest bug killer. OSGi provides tools like µservices that are very good in allowing assumptions to remain local.
Your layout looks very much like a web project, which imho is wrong since most code we have to develop ourselves should be independent of the technology used to present it. All this technology is likely to change in the near future since web applications are shifting rapidly to the browser, browsers are becoming fat clients again. I.e. the very modern REST interfaces already feel very old fashioned if you see what pure messaging is doing. All this volatility means that you want to make your modules as decoupled as possible.
So I would never couple any domain code to anything that is coupled to libraries that are coupled to web technology. These transitive dependencies are going to hurt you in the (near) future. Built small cohesive uncoupled modules and then use them as lego blocks to build your applications.