Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/tmslpm/hello-spring-layered-architecture

Last synced: 10 days ago
JSON representation

Host: GitHub
URL: https://github.com/tmslpm/hello-spring-layered-architecture
Owner: tmslpm
License: mit
Created: 2024-12-08T21:14:19.000Z (14 days ago)
Default Branch: main
Last Pushed: 2024-12-08T21:23:12.000Z (14 days ago)
Last Synced: 2024-12-08T22:26:26.631Z (14 days ago)
Size: 66.4 KB
Stars: 0
Watchers: 1
Forks: 0
Open Issues: 0
Metadata Files:
- Readme: README.md
- Contributing: .github/contributing.md
- License: license.md
- Code of conduct: .github/code_of_conduct.md
- Security: .github/security.md

Awesome Lists containing this project

README

# 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 "**B**usiness **L**ogic **L**ayer" 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 "**D**ata **A**ccess **L**ayer" 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 "**P**resentation **L**ayer" 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

```txt
┌───────────────────────────┐
│ │
│ 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.