We have this constant discussion in our project as to the granularity of our maven modules. We have come to agree that there may be differences in the needs of a framework (like spring) and an in-house application that is always deployed monolithically.
We also agree that it’s fairly sensible to hide implementation details of adapters to external systems behind a separate API module, so the implementation classes don’t bleed into the classpath of the main implementations. as But that’s as far as we go. It’s a web project so we have modules like ‘web’, ‘core’ and ‘adapter(s)’. We have multiple backends, but we don’t require plugability.
What criteria do you use for modularizing in maven ? Which modules do you make for web projects ?
In my opinion, the project division should be pretty fine grained, even for ‘only a webapp’.
I would make separate projects for the data access layer interfaces and implementation, business layer interfaces and implementation, and the webapp itself. I would also make atleast one ‘commons’ project for containing code relevant to more than one of the other projects. But this is just the beginning. I would not hesitate to extract a commons-util project for utility classes relevant regardless of the application that is being developed (String, Date, Reflection, etc). I would also make a project for useful utilities when doing testing (commons-test). And that’s just the next step … 😉
If I wrote generally useful code relevant to hibernate, I would put it in a hibernate-utils project. Useful Spring utilities would go in a spring-utils project etc. When doing this, many projects will only contain a single or a few packages, and the packages will commonly contain few classes.
My reasoning for doing this, is that it helps me think about the code I write. Is this REALLY business logic, or is it general String manipulation, Date manipulation, Hibernate specific logic etc? My layers become cleaner, and it becomes harder to get circular dependencies between packages and projects (we don’t want those). In addition, it becomes much easier to reuse code in other projects. There will always be other projects…
I have also found that it is easier for new developers to get a hang of the structure, because the projects become smaller and more manageable; it’s easier to start coding when you feel you don’t have to under stand everything.
As a last advantage to the fine grained approach, build times reduce because you don’t have to build everything every time.