guide structure

Table of Contents

• Project structure
  • Make jar not war
  • Package Structure

Project structure

The structure of a devon4j application is devided into the following modules:

• api: module with the API of your application. The API contains the required artifacts to interact with your application via remote services. This can be REST service interfaces, transfer-objects with their interfaces and datatypes but also OpenAPI or gRPC contracts.

• core: maven module containing the core of the application with service implementation, as well as entire logic layer and dataaccess layer.

• batch: optional module for batch layer

• server: module that bundles the entire app (core with optional batch) typically as a bootified WAR file.

Make jar not war

First of all it is important to understand that the above defined structure aims to make modules like api, core, and batch reusable maven artifacts, that can be used as a regular maven dependency. On the other hand to build and deploy your application you want a final artifact that is containing all required 3rd party libraries. This artifact is not reusable as a maven dependency. That is exactly the purpose of the server module to build and package this final deployment artifact. By default we first build a regular WAR file with maven in your server/target directory (*-server-«version».war) and in a second step create a bootified WAR out of this (*-server-bootified.war). The bootified WAR file can then be started standalone (java -jar «filename».war). However, it is also possible to deploy the same WAR file to a servlet container like tomcat or jetty. As application servers and externally provided servlet containers are not recommendet anymore for various reasons (see JEE), you may also want to create a bootified JAR file instead. All you need to do in that case is to change the packaging in your server/pom.xml from war to jar.

Package Structure

The package structure of your code inside src/main/java (and src/test/java) of your modules is described in our coding conventions in the sections packages and architecture-mapping.