damienbeaufils / spring-boot-clean-architecture-demo

An example of clean architecture implementation with Spring Boot

spring-boot-clean-architecture-demo

An example of clean architecture with Spring Boot

Foreword

This application is designed using a Clean Architecture pattern (also known as Hexagonal Architecture). Therefore SOLID principles are used in code, especially the Dependency Inversion Principle (do not mix up with the classic dependency injection in Spring for example).

Concretely, there are 3 main packages: domain, use_cases and infrastructure. These packages have to respect these rules:

• domain contains the business code and its logic, and has no outward dependency: nor on frameworks (Hibernate for example), nor on use_cases or infrastructure packages.
• use_cases is like a conductor. It will depend only on domain package to execute business logic. use_cases should not have any dependencies on infrastructure.
• infrastructure contains all the technical details, configuration, implementations (database, web services, etc.), and must not contain any business logic. infrastructure has dependencies on domain, use_cases and frameworks.

Install

./gradlew assemble

Test

./gradlew check

Mutation testing

./gradlew pitest

Run

./gradlew bootRun

spring-boot-clean-architecture-demo's Issues

Un peu de triche..

Merci pour ce projet.
Je cherchais un moyen pour utiliser la clean archi avec JpaRepository.
Il me semble que la façon dont tu l'as fais n'est pas totalement clean archi.
Ton Repo a des méthodes qui correspondent exactement aux noms des méthodes du JpaRepository.
Si je change le findAll et décide de le nommer "findAllDummies" ça ne marchera plus je pense (pas testé)
Du coup il y a une dépendance domain => infra
Non ?

A side note on the domain and use-cases layers

Just wanted to leave a note about the two layers. As written in the description, domain layer only cares about business logic, it represents business entities as classes that encapsulate the entities' state and behavior on that state. And use-cases layer (also called application layer) is responsible for coordinating all that business logic, use-cases here are the public interface of that layer. My point here is that details like persisting something into a database or fetching some other data from some service are really concerns of the application layer, they are a part of the application logic. Domain doesn't care about them. Also note that entities that you persist into the database need not map one-to-one to the domain entities. So really the DummyRepository interface should not be the part of the domain layer, it should go into the use-case layer. Also note that you have a default constructor in Dummy with a comment that it is required for JPA, so in the example the domain layer is kind of aware of infrastructure layer, which should not be the case. The solution for this would be to disconnect the entities in the domain from the entities that you persist and map between them in the use-cases layer.

To the users of this template, not that in simple to medium size projects there is almost no domain logic at all, so it makes sense to combine the two layers into one (called "operation script" approach) an example might be a simple CRUD based application for storing online articles. And generally such "clean architecture approach" is suitable for big scale application, where you have separate teams working on different parts of it. But for simpler projects, don't be afraid to deviate here and there from this model.