It is, of course, too late to suggest anything for a project of that scale that is well under way...but, for all it's worth, here are my thoughts on packaging. I am with you on modularity. Everyone talks about SOA, but most people continue to build application-centric architectures. In such architectures, services are not reusable for one obvious reason: people bundle things by their type rather then their relevance to a particular functionality. As the result, the implementation of a single functional piece is often sprinkled through a bunch of modules that have names like "model", "domain", "services", "daos", "configuration", etc. There are even worse examples: "exceptions" and "constants". Needless to say, such packaging makes everything tightly coupled with everything. So, if one developer is working on some kind of "User" functionality, he/she is simultaneously messing with your "model.user", "services.user", etc. This is a very common approach that many projects follow to one degree or another. Even code examples in books and on-line articles advocate that. No wonder, so many projects become so convoluted and dependent on themselves. Why people continue to do so amazes me! As if no one has ever come across a situation when they needed to re-use the same functionality they had just implemented in a web application - for some end-of-day batch process... Except, they can't take it out of their web application because it is totally dependent on the web app's configuration, domain model, daos, services, constants, and exceptions! D'oh!
The simple - and most obvious, I would think - solution is to bundle classes in modules according to their functional/problem area. Each module will provide the problem-specific Domain Model and API. It may also provide default implementations of the service and DAOs that applications may re-use if they can. Or, each client application can provide their own implementation of the service that conforms to the API, if necessary. DAOs often will be application-specific if different apps talk to different data sources. For example, you will have modules like this:
com.mycompany.core (for all your core/common classes, utilities, and, perhaps some marker interfaces, etc.)
com.mycompany.user (User Domain Model, User API, user DAO API+ user svc reference implementation that may be re-used by client apps)
com.mycompany.someservicearea (Domain Model, API, etc.)
Then, you will have your applications that will have your re-usable "platform" components as dependencies. You may have web apps, schedulers, batch applications, etc. Each may provide some app-specific domain objects, DAO implementations, presentation-specific packages, etc. But everything that is reusable will live outside - in your "platform".
com.mycompany.myapplication.etc.
So, your applications should live parallel to your reusable functionality-specific modules.
For example, take a look at how the Spring modules are packaged. There is Spring Core, and each individual Spring piece you want to use requires you to include only the minimum dependencies, not the whole Spring stack.
Agile is good - as long as it is not understood as completely chaotic and messy. In fact, the approach I have just described really helps in agile development because it makes it easier to view modules as complete "black boxes" between the iterations.
Cheers,
Constantine
P.S. Sorry for the off-topic post!
