I am developing an application that in essence is built out of many smaller but isolated applications, with one web project tying them all together and I am debating about the architecture of my eclipse projects and context files.
Currently I have (and have traditionally used) an ApplicationFramework and ApplicationWeb project. Service/Dao/Domain classes reside in the application framework along with the service/dao context files so they can be unit tested and isolated from the web.
In the web project web.xml, I refer to the context files from the framework project and also any context files the web might be using.
This has worked well in the past, but I am noticing that since I will have multiple smaller projects, each with their own services and domain objects, it may make sense to divide them into their own projects as follows:
With ApplicationWeb referring to all of them. This would of course mean each subproject has its own context files, which may bring a new set of issues, such as do I then need multiple cache managers to configure the application caches separately and would that be inefficient (or more efficient?), how would the ehcache MBean handle multiple managers etc.
The alternative is to have the code reside in different packages within the main application framework, although I have a feeling that will grow very fast. Some of these smaller applications will not have much code, some may have a lot more, although I expect them all to have persistent objects of some kind.
From an architecture point of view I believe there is value in isolating the subprojects, and typing this out I realize my only big hang up is the multiple cachemanagers, so I will look into that to start. But I was wondering if anyone had any high level insight they could share.