Skip to content

guide structure modern

devonfw-core edited this page Jul 26, 2021 · 10 revisions

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 escpecially 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 is generating 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

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

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
   └──.service
      ├──.«Component»RestService
      ├──.mapper
      |  └──.«BusinessObject»Mapper
      └──.model
         └──.«BusinessObject»Dto
Clone this wiki locally