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

Hexagonal architecture on kotlin
https://github.com/naspredam/rest-spring-boot-kotlin-hexagonal-architecture

gradle jpa-hibernate kotlin spring-boot

Last synced: 6 months ago
JSON representation

Hexagonal architecture on kotlin

• Host: GitHub
• URL: https://github.com/naspredam/rest-spring-boot-kotlin-hexagonal-architecture
• Owner: naspredam
• Created: 2021-01-06T14:44:56.000Z (almost 5 years ago)
• Default Branch: main
• Last Pushed: 2022-03-19T16:59:23.000Z (over 3 years ago)
• Last Synced: 2025-04-15T20:09:29.574Z (8 months ago)
• Topics: gradle, jpa-hibernate, kotlin, spring-boot
• Language: Kotlin
• Homepage:
• Size: 204 KB
• Stars: 6
• Watchers: 2
• Forks: 3
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
# rest-spring-boot-kotlin-hexagonal-architecture

This project is to expose my interpretation of the hexagonal architecture, under spring-boot framework with kotlin language.

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.