https://github.com/naspredam/rest-spring-boot-multi-project-hexagonal-architecture

Hexagonal architecture with DDD and multi project gradle approach
https://github.com/naspredam/rest-spring-boot-multi-project-hexagonal-architecture

clean-architecture gradle hexagonal-architecture java multiproject rest spring-boot

Last synced: 2 months ago
JSON representation

Hexagonal architecture with DDD and multi project gradle approach

• Host: GitHub
• URL: https://github.com/naspredam/rest-spring-boot-multi-project-hexagonal-architecture
• Owner: naspredam
• Created: 2021-01-06T18:40:22.000Z (about 4 years ago)
• Default Branch: main
• Last Pushed: 2021-01-06T18:45:32.000Z (about 4 years ago)
• Last Synced: 2024-11-16T11:33:46.885Z (3 months ago)
• Topics: clean-architecture, gradle, hexagonal-architecture, java, multiproject, rest, spring-boot
• Language: Java
• Homepage:
• Size: 197 KB
• Stars: 7
• Watchers: 3
• Forks: 9
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# rest-spring-boot-hexagonal-architecture

This project is to expose my interpretation of the hexagonal architecture, under spring-boot framework using gradle multi-project.

This approach seems a little more complex, but it has some advantages, as be able to limit the dependency packages per module. What I can see that this could be useful is on the case of having a monolith. On micro-services, as it is expected that the domain should be under a boundary context, this should not be a problem to have in a single project.

The diagram of the hexagonal architecture relies on the following:

![Hexagonal architecture diagram](img/hexagonal-architecture.png)

I have tried to take a diagram that I have seen common on different articles, even though I saw port/adapter to be swap.

This architecture follows the clean architecture from Uncle bob:

[https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)

This project is following this diagram on spring-boot framework.

## Application diagrams

On this I was doing the following approach diagram:

![Application diagram](img/hexagonal-arch-spring-naspredam.png)

Where we have as part of the application is:

- REST implementation

- Database connection

The colors meant to be:

- Orange: this is the domain model of our application, that is located on `com.example.service.user.domain`

- Blue: this is the application itself, where we have the logic and the ports (to apply this logic from and to). The package is: `com.example.service.user.application`

- Green: this is the package `com.example.service.user.adapter`, where are the implementation of the ports. It was decided to keep the repositories and the controllers, even though this could be moved to the `infrastructure` package.

What was not played out on this diagram was the package:

`com.example.service.user.infrastructure`

This package is cross, so it was not having a flow on the diagram, but impacts to be defined shared components.

## Domain model

The domain model is a simple one, for user management.

This diagram it is just a simple information for eventual `User` domain. We can see the following domain model diagram:

![Domain model diagram](img/user%20domain%20model.png)

where the colors here represents:

- Orange: entity or root aggregate of our domain

- Blue: value objects

This domain has a functions class, where it is a bunch of functions to access to `User` entity information.

## Architecture tests

It was implemented the arch rules from [arch unit library](https://www.archunit.org/).

The tests are located on:

```text

com.example.service.user.architecture.*

```

## Test strategy

The tests develop were doing unit tests for each class of the project.

Do integration test on the controller, which is our application entry point.