Physical software project structure
Higher level folder hierarchy
Golden rule: Those artifact which’s lifecycle is the same must be stored in the same place.
With other words: all source code, documentation, helper must be stored in the version management system in the same place, under a common folder structure. The lifecycle of that folder structure must be the same. You have to avoid keeping a java folder structure independently from the database and test scripts. In any other case you have double release related maintenance (branching, merging)
Maven folder structure
Setting up multiproject maven environment is not a trivial task.
You must understand the difference between sub-modules, parent-child projects.
- Maven Best Practices
- Good section about multi-module vs. inheritance
- Best practices for multi-module project organisation
Organizing maven modules are not the question of numbers. The key is the well organized project structure.
A (probably) good example:
- toolbox: general, reusable components
- data: all basic business entities, hibernate mapping, simple and reusable DAO-s.
- project-service: the core business functionality
- project-web/front: front-end components only.
Of course you could have more or less. Depending on the project.
- so called “common” project which contains 2/3 of the total source code of the project
- module represented in subproject, but the project is not standalone. Have several seriouse dependency on such a projects which are is logically independent from that.
- subproject with only a very few number of classes. Especially if they are not independent components.
- Physical software project structure
- Service layer
- Data access layer
- Spring MVC
- Web view
- Jawr, webjars, bootstrap, Spring setup trick
- Jakarta Equivalence Relation
- Difficult to test example refactoring