Hello Spring Layered Architecture

• run

gradlew :src:app:bootRun

• build

gradlew :src:app:bootJar

output build: ./src/app/build/libs/{rootProject.name}-app-{version}.jar

Intro

I created this template to practice working with Gradle subprojects. I decided to build a Gradle project composed of subprojects representing each layer of a typical Spring application (DAL, BLL, PL) since this pattern is often recommended for large, complex projects. With this in mind, I designed the template for scalability.

To simplify dependency management, I centralized version control using Gradle's Version Catalogs, except for versions already managed by Spring Boot.

Each layer is implemented as an independent subproject, with a dedicated subproject serving as the single entry point for the application. This entry point aggregates the three layers, forming the complete application. Gradle's configuration enforces strict separation between layers: for example, the PL cannot access the DAL directly, requiring the BLL as an intermediary. This setup ensures clear responsibilities, simplifies testing and enables several developers to work simultaneously on different layers without interference, provided proper groundwork is laid.

To streamline the setup of all subprojects, I created a custom Gradle plugin in the buildSrc directory.

• ./buildSrc/src/main/groovy/project-setup.gradle <- plugin

This plugin centralizes common configurations such as dependency management, repository settings, Java toolchain definitions, and encoding options. It ensures consistency across all subprojects by applying standardized configurations like:

• JUnit and Mockito for testing
• MapStruct for mapping
• Lombok for code generation

Additionally, it simplifies Java compatibility settings and optimizes compilation with UTF-8 encoding and target compatibility enforcement. This approach minimizes repetitive configuration and ensures a cohesive setup across the entire project.

Key Technical Points:

1. Layer Independence

   • Each layer is completely independent, ensuring easy testing and project scalability.
   • Dependencies between layers are explicit and strictly limited to authorized interactions, enforcing a modular architecture.

2. Strict Separation of Concerns

   • The Presentation Layer (PL) cannot directly access entities defined in the Data Access Layer (DAL).
   • The DAL has no knowledge of business logic or presentation-related components.

3. Data Transfer Objects (DTOs)

   • DTOs are used to encapsulate data exchanged between the presentation and business logic layers.
   • JPA entities are never exposed directly in JSON responses, ensuring better security and encapsulation.

4. Automatic Mapping with MapStruct

   • MapStruct is used to automate the conversion between entities (DAL) and DTOs (PL), reducing boilerplate code.

5. Code Generation with Lombok

   • Lombok simplifies development by automatically generating getters, setters, constructors, and other utilities.

6. Strict Gradle Configuration

   • Gradle enforces strict separation between subprojects, ensuring module independence and eliminating circular dependencies.
   • This configuration strengthens the isolation and interoperability of the layers.

7. Centralized Dependency Management

   • All dependency versions, except those managed by Spring, are centralized in a Gradle Version Catalog.
   • This ensures consistency across modules and simplifies version updates.

Project Structure

project root

root
|- buildSrc
|  \- ... (💡Pre-compiled Script Plugin)
|
|- gradle
|  |- wrapper/...
|  \- libs.versions.toml (💡Version Catalogs)
|
|- src (💡Spring Application)
|   |--- app
|   |    \- src/main/../../Main.java (Spring Entry)
|   |
|   |--- bll
|   |    |- src/main/..
|   |    |- src/test/..
|   |    \- build.gradle
|   |     
|   |--- dal
|   |    |- src/main/..
|   |    |- src/test/..
|   |    \- build.gradle
|   |
|   \--- pl
|        |- src/main/..
|        |- src/test/..
|        \- build.gradle
|
\- ...

• App: The "app" subproject is the main entry point for your Spring Boot applications. All other subprojects inherit the dependencies of this project.
• BLL: The "bll" subproject is the "Business Logic Layer" of your application. It typically contains classes that implement the business logic, including business rules, data processing algorithms, and more.
• DAL: The "dal" subproject is the "Data Access Layer" of your application. It is responsible for data access, including database interactions and communication with other data sources. It usually contains classes for performing data read/write operations, executing database queries, managing connections, and handling related tasks.
• PL The "pl" subproject is the "Presentation Layer" of your application, where the user interface (UI) is typically implemented. This layer may include classes for UI components, user input handling, data display, and other related functionalities.

project logic

   ┌───────────────────────────┐
   │                           │
   │           A P P           │
   │                           │
   │      ┌─────────────┐      │
   │      │             │      │ 
   │      │     P L     │      │ 
   │      │             │      │ 
   │      └─┬─────────▲─┘      │ 
   │        │         │        │ 
   │      ┌─▼─────────┴─┐      │ 
   │      │             │      │ 
   │      │     BLL     │      │ 
   │      │             │      │ 
   │      └─┬─────────▲─┘      │ 
   │        │         │        │ 
   │      ┌─▼─────────┴─┐      │ 
   │      │             │      │ 
   │      │     DAL     │      │ 
   │      │             │      │ 
   │      └─────────────┘      │ 
   │                           │  
   └───────────────────────────┘              

Project Dependency Management

The project uses Gradle's Versions Catalog functionality to manage its dependency versions centrally and efficiently.

This ensures consistency and avoids version conflicts.

For the version catalog file, see the libs.versions.toml file located in the ./gradle/libs.versions.toml directory.