Many times, I am trying to resolve several basic or complex Maven / Java EE project structure issues, on my day work. In order to provide the solutions, I often end up experimenting with the project structure and it’s effectiveness.
It’s worth investing some time on application structure for big projects (especially Java EE). If not, it’s cannot be changed at the end.
It’s important to understand the application structure and the underlying build tools when you start working on a project.
Maven might be wise choice because it’s helps you build a better project quickly and effectively.
Maven helps in the following areas :
- Making the build process easy
- Providing a uniform build system
- Providing quality project information
- Providing guidelines for best practices development
- Allowing transparent migration to new features
Best practices (maven’s) for development
- Keeping your test source code in a separate, but parallel source tree
- Using test case naming conventions to locate and execute tests
- Have test cases setup their environment and don’t rely on customizing the build for test preparation.
Maven is designed to be flexible, but only to an extent. So, using maven in your project means, you need to reorganize your project (if not in good shape) and adhere to the maven’s conventions.
Random Quote :
“It is good to break conventions in your life and in your coding, but never with Maven.”
There are number of ways you can organize your project’s sub-modules.
- Single Bulk Module
- Module by Class Type
- Module by Functionality Area
1) All the modules can be grouped together as a single bulk project. But it’s not recommended anyway.
2) Module by class type : Project can be splitted into sub-projects/modules. And each module are used to group together all classes that comprise, but are not limited to, a layer in the project’s architecture. For example, a module could contain all classes that make up the project’s service or persistence layers or a module could contain all the model class (i.e., jpa or entity beans).
3) Modules by functionality area : Project’s sub-modules are organized by functional area (component based) i.e, vertical slice of the application including model beans, service layer, repositories etc..
Example for ‘Module by class type’:
Example for ‘Module by functionality’:
It’s always necessary for each module to have it’s own unit tests.
Pros and Cons of Class Type :
+ Pretty maintainable in that you always known where to find stuff
+ Build order is very straight forward
– Circular dependencies
– Classes with totally different responsibilities are all mixed up together making it difficult to re-use functionality in other projects
Pros and Cons of Functionality Type :
+ Modules are highly decoupled
+ It’s far simpler to re-use a functional area of code in other projects
– Build order might be complex because of its dependencies
You may have noticed that both of them are not 100% perfect.
Also there are few modules which are repeated in both these types in the project. Because it’s always wise to keep the necessary things together i.e., creating a separate database module allows you to change your project’s database implementation fairly easily, which may make testing easier in some circumstances and likewise, having a separate web module allows you to re-skin your code easily.
At the end of the day, it really depends on the need of the project and it’s existing structure. And you can also mix-match both these types, if helps to solve your problem effectively.