We are using multi-module projects for the components of our software. The sub-modules spread into api and implementation. The advantage is that other maven projects can import the API part only and doesn't see the implementing classes.
Is this a best practice? It is not very fine grained which might lead us to big packages in the end. I like the tiered approach more, which would mean modules like client, logic, persistence. Each could have an distinct api and an implementation module. Would that be too much, because that means having 6 modules instead of 2?
6 modules shouldn't be a problem. I work on a project with more then 50 modules without problems caused by the number of modules.
Changing the scope and dependencies between modules can get a little confusing and is much easier (but not easy) when you use just java package plus ruled for allowed dependencies enforced by a tool like JDepend or Structure101.
Therefore I would create a module for something that I want to deploy or not deploy independently of the other stuff.
I would not create modules just to prevent dependencies between parts of the application, but use other tools for that.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With