devonfw guide

Modern project structure

With trends such as cloud, microservices, lean, and agile, we decided for a more modern project structure that fits better to recent market trends. When starting new projects with devonfw, and especially in the context of cloud-native development, we strongly recommend this modern approach over the classic structure.

Modules

Due to trends such as microservices, we are building smaller apps compared to moduliths. For simplicity, we therefore do not split our app into different modules and keep everything top-level and easy.

In addition to java and resources, we also add helm for helm templates and docker for docker scripts (e.g. Dockerfile) in src/main:

├──/src
|  ├──/main
|  |  ├──/docker
|  |  ├──/helm
|  |  ├──/java
|  |  └──/resources
|  └──/test
|     ├──/java
|     └──/resources
└──/pom.xml

Deployment

For modern projects, we strongly recommend that your build process generates the final deliverable as an OCI compliant container. Further, to go fully cloud-native, you should build your app as a native image via GraalVM AOT compiler. Therefore, we recommed to use quarkus as your main framework. In case you want to go with spring, you may consider using spring-native.

Layers

The package structure of your code inside src/main/java (and src/test/java) of your app is described in our coding conventions in the sections packages. For the modern project structure, the layers are defined by the following table:

Layer «layer» Description

Layer	«layer»	Description
service	`service`	The service layer exposing functionality via its remote API. Typical protocol is REST. May also be any other protocol you are using such as gRPC.
dataaccess	`dataaccess`	The data-access with the entities and DB access. Use sub-package (in `«detail»`) `repository` for repository and `dao` for DAOs. Also we recommend to put entities in `model` sub-package.
logic	`logic`	The logic layer with the functionallity providing the business value.
common	`common`	cross-cutting code not assigned to a technical layer.

service

service

The service layer exposing functionality via its remote API. Typical protocol is REST. May also be any other protocol you are using such as gRPC.

dataaccess

dataaccess

The data-access with the entities and DB access. Use sub-package (in «detail») repository for repository and dao for DAOs. Also we recommend to put entities in model sub-package.

logic

logic

The logic layer with the functionallity providing the business value.

common

common

cross-cutting code not assigned to a technical layer.

Architecture Mapping

In order to help you to map the architecture, packaging, layering, etc. to the code and see where different code elements should be placed, we provide this architecture mapping:

«root»
├──.«component»
|  ├──.dataaccess
|  |  ├──.repo
|  |  |  ├──.«BusinessObject»Repository
|  |  |  ├──.«BusinessObject»Fragment
|  |  |  └──.«BusinessObject»FragmentImpl
|  |  ├──.dao [alternative to repo]
|  |  |  ├──.«BusinessObject»Dao
|  |  |  └──.«BusinessObject»DaoImpl
|  |  └──.model
|  |     └──.«BusinessObject»Entity
|  ├──.logic
|  |  ├──«BusinessObject»Validator
|  |  └──«BusinessObject»EventsEmitter
|   |  └──.Uc«Operation»«BusinessObject»[Impl]
|  └──.rest
|     └──.v1
|        ├──.«Component»RestService
|        ├──.mapper
|        |     └──.«BusinessObject»Mapper
|        └──.model
|           └──.«BusinessObject»Dto
└──.general
   └──.dataaccess
      └──.model
         └──.ApplicationPersistenceEntity