Maven : How to have Modular project structure based on Business Functions

[shukla raghav]

Hi i am not a maven expert, but i am impressed with maven's dependency management. I have a team of 8-10 developers and we are starting development from scratch. I have a specific goal that i am hoping could be achieved through maven. In professional environments i have seen several big applications with poor application build structures that would take 50 to 90 (average 60 minutes) minutes to build and deploy and start the server. In case if a developer makes just 4 changes a day incrementally he is bound to loose nothing less than 4 hrs. That is sheer wastage !!! I understand maven can help reduce the build time certainly because we don't need to build the entire application. we can have a partial build and deploy. But there is one more thing that i wish to achieve.

Where ever i have seen an example of Maven Based Enterprise Webapplication structure, It is structured as Technical Layer rather than Business Modules. In concrete terms

Here is an extract from Parent POM of a test application. And most of the other examples found online have similar structure

<modules>
        <module>simple-client</module>
        <module>simple-model</module>
        <module>simple-service</module>
        <module>simple-persist</module>
        <module>simple-webapp</module>
    </modules>

Here we can see that the sub-modules are divided based on technical layers (Client layer, Service Layer, Domain (model) layer, Persistence Layer and then a Webapp component that would wrap everything in a war). This will help the developers separately compile, package and deploy any of the above module (i.e. client,service, model, persistance..etc).

But in actual environment why would someone want to build a domain layer separately. or entire persistence layer separately. Teams work on seperate Business Modules and that is what they are interested in compiling, packaging, integrating and deploying. For example for an educational software there are modules like Registration System (RegistrationController.java, RegistrationService.java, RegistrationDAO.java and list of Domain Objects) and Assignment System (controller,service, dao, domain etc)...and so on other modules. In a team of 10, possibly a group of 3 devs (group-A) could be working on registration system and another 2 (group-B) could be working on Assignment System and so on. In such a case All that Group-A is interested in is compiling, packaging, deploying code related to its own Module that is Registration System. So why not have a build structure like

<modules>
        <module>simple-Registration</module>
        <module>simple-Authorization</module>
        <module>simple-Assignment</module>
        <module>simple-Assessment</module>
        <module>simple-webapp</module>
    </modules>

with each module having source from all layers.

Are there any complexities involved? How do we achive it ?

[Saif Asif]

Greetings Shukla,

Before going in the details , I would first simply ask you to work out your requirements and need. Because the structure of the project is supposed to be as per the demand and requirements. Yes maven can help you out in speeding up ( or should I say automating the build process ) and the technical layer division of modules as you stated

<modules>
<module>simple-client</module>
<module>simple-model</module>
<module>simple-service</module>
<module>simple-persist</module>
<module>simple-webapp</module>
</modules>

is the most ideal one since your persistence layer , presentation layer and business layers are all separate from one another ( as it should be ) .

However if you divide the project modules based on components

<modules>
<module>simple-Registration</module>
<module>simple-Authorization</module>
<module>simple-Assignment</module>
<module>simple-Assessment</module>
<module>simple-webapp</module>
</modules>

you will end up with an extremely mixed up complicated project hierarchy. Each module ( e.g the Registration and the Authorization ) will both require to have some part of the persistence layer in them and you may even end up having duplication issue.

Its ideal that you construct your project hierarchy keeping all the layers separate from each other.

[shukla raghav]

This is what maven should be able to do for us i.e. Take care of inter-dependencies in the project. Keeping your point also in mind we can make the build even more granular as follows.

We can have following kind of build structure

Core Module : Registration System
Sub Module : Controller
Sub Module : Service
Sub Module : DAO
Core Module : Authorization System
Sub Module : Controller
Sub Module : Service
Sub Module : DAO
Core Module : Assignment System
Sub Module : Controller
Sub Module : Service
Sub Module : DAO
Core Module : Assessment System
Sub Module : Controller
Sub Module : Service
Sub Module : DAO

There will be a separate jar created for every submodule. At the time of build all sub-modules will be rolled up to a jar Core Module jar. All Core Module jars will be clubbed together along with Client Code and Domain jar into a .war file that will be application deployable.

Is it possible? This way we can better manage dependency and faster build since a developer who makes changes to a DAO for a specific core module say Registration System just needs to build the specific DAO.

If this is possible and OK then what do you think should be the relationship between Core Module and submodules ( Parent-Child i.e. inheritance or Aggregation i.e. module within module).

[Jayesh A Lalwani]

You need to consider reuse between modules. For example, your DAO modules might need to share code with each other, or your controller modules will have some shared filters, or your JSPs might have shared templates/resources/static files.

Not saying that what you are trying to do won't work. Just something for you to think about. Maybe you can have shared module where your shared code lives in, and gets built by everyone.

[shukla raghav]

Hi Jayesh, You are correct thinking about shared services is important. which shouldn't be a problem since maven defines inheritance so all the common services can be built separately in the parent module and inherited by the rest of the modules.

Maven is one amongst the GREAT tools. And with great tools we don't need to think so so much. Or else it is not a GREAT tool. In that case why not switch back to writing Ant scripts only. I see that the Idea of maven is pretty simple. It says A. Define List of Modules in the Parent Module B. If there are interdependency amongst modules then define it as a <dependency> in their respective POM files. Before building maven generates a dependency order that is visible in the reactor summary. So whether it is complicated dependency or simpler, its not for us to think, let maven do it.

[Peter Johnson]

Do not assume that just because you have one module relying on several others that you have to set up a master module with sub modules. Instead, set each up as a separate project with its own artifact and use dependencies to define how the artifacts relate to each other. Dealing with separate projects is much simpler than having to deal will master/submodules. Every project my colleagues have set up that way (against my advice) continues to cause them problems.

[Jayesh A Lalwani]

shukla raghav wrote:Hi Jayesh, You are correct thinking about shared services is important. which shouldn't be a problem since maven defines inheritance so all the common services can be built separately in the parent module and inherited by the rest of the modules.

You cannot put code in a parent pom. You can have a shared module that the parent pom can depend on, and the child pom will all inherit the dependency

Maven is one amongst the GREAT tools. And with great tools we don't need to think so so much. Or else it is not a GREAT tool. In that case why not switch back to writing Ant scripts only.

Actually, one of the strengths of maven over Ant is that it makes it easy for you to do the things the right way, and difficult to do the things the wrong way. It forces you to think. Ant doesn't force you to think, and you get to a point where the whole Ant script looks like a big bowl of spaghetti. The whole point of using Maven is to think through your module structure. Once you have figured your module structure out, it will do the legwork of dependency resolution for you. However, that's no excuse to not think about the structure of your modules.