Why and when to create a multi-module Maven project?

Question

I have a general question about Maven\'s multi module project. When and why to go for it?

Answer 1

It seems that this question is more about software in general. Maven is just one way of doing it.

I will qoute a few lines from "Continuous Delivery", by Jez Humble

What is a component? This is a horribly overloaded term in software, so we will try to make it as clear as possible what we mean by it. When we talk about components, we mean a reasonably large-scale code structure within an applica- tion, with a well-defined API, that could potentially be swapped out for another implementation. A component-based software system is distinguished by the fact that the codebase is divided into discrete pieces that provide behavior through well-defined, limited interactions with other components. The antithesis of a component-based system is a monolithic system with no clear boundaries or separation of concerns between elements responsible for different tasks. Monolithic systems typically have poor encapsulation, and tight coupling between logically independent structures breaks the Law of Demeter.

...

Employing a component-based design is often described as encouraging reuse and good architectural properties such as loose coupling. This is true, but it also has another important benefit: It is one of the most efficient ways for large teams of developers to collaborate.

...

Many projects are fine with a single version control repository and a simple deployment pipeline. However, many projects have evolved into an unmaintain- able morass of code because nobody made the decision to create discrete compo- nents when it was cheap to do so. The point at which small projects change into larger ones is fluid and will sneak up on you.

...

Finally, it’s worth noting Conway’s Law, which states that “organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”4 So, for example, open source projects where developers communicate only by email tend to be very modular with few interfaces. A product developed by a small, colocated team will tend to be tightly coupled and not modular. Be careful of how you set up your development team—it will affect the architecture of your application.

I find amazing how lucid and accurate this last statement is. And I strongly recommend that book! :-)