Modern project structure

Warning
Hey there! Seems like you are still using the documentation of our legacy Java repository. Since it won’t be maintained anymore, we recommend you to checkout the new Java page here.

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

Warning
Hey there! Seems like you are still using the documentation of our legacy Java repository. Since it won’t be maintained anymore, we recommend you to checkout the new Java page here.

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

Warning
Hey there! Seems like you are still using the documentation of our legacy Java repository. Since it won’t be maintained anymore, we recommend you to checkout the new Java page here.

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

Warning
Hey there! Seems like you are still using the documentation of our legacy Java repository. Since it won’t be maintained anymore, we recommend you to checkout the new Java page here.

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

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.

domain

domain

The domain with the data-model 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

Warning
Hey there! Seems like you are still using the documentation of our legacy Java repository. Since it won’t be maintained anymore, we recommend you to checkout the new Java page here.

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»
|  ├──.domain
|  |  ├──.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
   └──.domain
      └──.model
         └──.ApplicationPersistenceEntity
Last updated 2022-11-30 15:22:16 UTC