It is advisable to package the enterprise project into a single deployment artifact that emerges from a single project module. The number and structure of deployment artifacts then maps the structure of the software projects. If other artifacts emerge from the project, they are organized in separate project modules as well. This enables an understandable and lightweight project structure.

Usually, an enterprise project will result in a shippable JAR or WAR file, originating from a single project module. Yet sometimes, we do have good reasons to create modules that are shared among projects. These are then sensibly crafted as own project modules that build own artifacts, for example JAR files.

There are still other motivations for multi-module projects. System tests that verify a deployed enterprise application from the outside don't necessarily have dependencies on the production code. It makes sense, in some situations, to organize these tests in separate project modules that are part of a multi-module project.

Another example is frontend technologies that are just loosely coupled to the backend application. With modern client-centric JavaScript frameworks being used more and more, the coupling to the backend also decreases. The workflow and life cycle of developing frontends can vary from the backend application. Therefore, it can make sense to split the technology into several sub-projects or even several software projects. The topic, Structuring for modern frontend technologies, covers how to tackle these situations.

These situations, however, also fit the concept of mapping artifacts in the broader sense to project modules. A system test project is used and executed separately from the production code. Developing and building the frontend project could equally be differ from the backend part. There may be some other situations where it is advisable as well.