Maven multi-module cut

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.

Having the interface as a separate module seems like a fine approach to me. It makes it much clearer what your dependencies are and can help your code avoid untoward coupling to implementation classes. You may still need a runtime dependency on the implementations if you're doing stuff like dynamic class instantiation, but that's much looser so you won't be getting into so much trouble there.

I see no reason at all to try to keep the number of modules small; they're just structure that's introduced to make it clearer what's going on and to enforce what can interact with what. You could even have multiple modules that can be used in particular rôles, so that you can (for example) support the quirks of particular databases in your persistence layer, with which modules are actually used being decided by which Maven profile is in use. (In my code, I use this to separate out the few platform-specific parts of the code from the large majority of platform-independent parts.)

What we learned in several years working with a osgi project with about 200 modules (bundles) is that is much better cutting bundles based on similar UseCases (login - accounting - store) rather than logical layer (frontend - logic - persistence).

If some module starts having duplicating code (like jdbc/orm stuff) then we add a new "technological" module with absolutely no knowledge of our Business (as opposed to the persistence layer) and we import it in the persistence layer of the modules that require it.

It's not clear why you would export an API from all layers of your application. Typically in a 3 layered GUI -> Service -> DAO structure (is this analagous to your Client -> Logic -> Persistence?), you might want to export the Service layer as a programmatic API for other applications, but the GUI would presumably be too coupled to the implementation to be worth having a separate API.