JoinedWorkz

Appearance

SpringBoot target platform design ​

The SpringBoot platform defines a domain-centric target architecture for generated Spring Boot services. This page focuses on the runtime layout of a typical service – the layers, responsibilities and how they collaborate.

The modelling and generator support for this architecture is described separately in:

At a high level the target architecture looks like this:

Controller / API → Use-case handlers → Domain services → Data access service → Persistence

Routing to external systems is handled via gateways; long-running processes are handled by explicit process management components.

1. Layers and responsibilities ​

1.1 Domain layer (core) ​

The domain layer is the core of the SpringBoot target platform and should be:

  • independent of any specific use case,
  • as independent of technical frameworks as possible.

Typical contents:

  • Domain data types (DTOs representing domain objects, enums, projections, later aggregates)
  • Domain services (use‑case independent, reusable)

Guiding rules:

  • no dependency on JPA entities or Spring Web classes,
  • domain services operate only on domain types.

1.2 Use‑case layer (handlers) ​

The use‑case layer contains handler classes invoked from controllers. They:

  • orchestrate one concrete use-case,
  • call domain services and data access services,
  • enforce use‑case level invariants.

Handlers do not handle web concerns or mapping.

1.3 Controller and API layer ​

This layer exposes HTTP endpoints and maps between API DTOs and domain types. It consists of:

  1. API interfaces
  2. Controller implementations

Mapping is generated using MapStruct.

1.4 Persistence layer ​

Contains:

  • JPA entities
  • Spring Data repositories

It represents the storage model and is intentionally kept separate from domain logic.

1.5 DataAccessService layer ​

XxxDataAccessService:

  • wraps repositories,
  • maps entities to detached data objects (later aggregates),
  • ensures no JPA entities leak into domain/use‑case layers.

1.6 Gateway layer ​

Abstraction for external service calls.
Currently generated only partly (OpenAPI YAML for called APIs).

1.7 Process management ​

Not generated; can be implemented manually or via BPMN engines.

2. Generated packages in the example project ​

Examples:

  • entity → JPA entities
  • repository → Spring Data repositories
  • das → data access services
  • dto → API DTOs
  • mapper → MapStruct mappers
  • api → controller‑level API contracts
  • controller → REST controllers

Execution flow:

  1. controller → 2. mapping → 3. handler or DAS → 4. repository → 5. mapping → response.

3. Single‑module vs multi‑module layouts ​

Single‑module
Good for prototypes.

Multi‑module (recommended)
Domain, persistence, web, gateway split into modules.
Supported through core, api, backend layers and outlet routing.

4. Summary ​

The SpringBoot target platform is:

  • domain‑centric
  • strongly decoupled
  • mapping‑driven (MapStruct)
  • persistence‑isolated
  • generator‑friendly