Implémenter une Clean Architecture dans un projet Spring Boot monolithique : une approche pratique

L'architecture logicielle est un pilier fondamental pour garantir la pérennité, la maintenabilité et l'évolutivité des applications. Dans l'écosystème Java, Spring Boot est devenu un choix prédominant pour le développement d'applications monolithiques grâce à sa rapidité de mise en œuvre et sa robustesse. Cependant, la croissance des fonctionnalités peut rapidement transformer un projet monolithique en un "big ball of mud" difficile à gérer.

La Clean Architecture, popularisée par Robert C. Martin (Uncle Bob), offre une solution élégante à ce défi. Elle propose une séparation claire des préoccupations, rendant le code indépendant de l'infrastructure, de l'interface utilisateur et même de la base de données. Cet article explore comment un développeur Full Stack Java Spring Boot + Angular comme Laty Gueye Samba, basé à Dakar, peut implémenter une Clean Architecture dans un projet Spring Boot monolithique, transformant ainsi un système potentiellement complexe en une application modulaire et facile à tester.

L'objectif de cette approche pratique est de démontrer qu'il est possible d'appliquer des principes d'architecture avancés même dans un cadre monolithique, préparant ainsi le terrain pour une scalabilité future ou une éventuelle migration vers des microservices, tout en assurant une qualité logicielle élevée dès le départ. Laty Gueye Samba, Développeur Full Stack Dakar Sénégal, met en lumière l'importance de ces pratiques dans des environnements de développement exigeants.

Les principes fondamentaux de la Clean Architecture dans un contexte Spring Boot

La Clean Architecture se base sur le principe de l'inversion de dépendance et de la séparation des préoccupations, organisant le code en couches concentriques. Chaque couche interne ne doit dépendre d'aucune couche externe. Pour un projet Spring Boot monolithique, cela se traduit par les couches suivantes :

• Entities (ou Domain) : Le cœur de l'application. Cette couche contient les règles métier fondamentales et les entités (objets métier purs) qui encapsulent ces règles. Elle est totalement indépendante.
• Use Cases (ou Application) : Contient la logique métier spécifique à l'application. Les cas d'utilisation orchestrent les flux de données vers et depuis les entités. Cette couche dépend de la couche Entities mais est indépendante des couches externes. Elle définit des "ports" (interfaces) pour interagir avec les couches externes.
• Interface Adapters : Adaptateurs qui convertissent les données du format des couches externes (par exemple, HTTP pour les contrôleurs, SQL pour la base de données) au format des couches internes (Entities, Use Cases) et vice-versa. Cela inclut les contrôleurs REST, les implémentations de dépôts (repositories), etc.
• Frameworks & Devices : La couche la plus externe, englobant les détails techniques tels que la base de données, le framework web (Spring Boot MVC), les UI, les serveurs, etc. Cette couche dépend de toutes les autres.

L'implémentation de ces principes dans un projet Spring Boot permet de découpler la logique métier essentielle des détails techniques d'implémentation. Cela renforce la testabilité, car les règles métier peuvent être testées sans l'intervention de la base de données ou de l'interface utilisateur.

Structurer un projet Spring Boot avec la Clean Architecture

Pour mettre en œuvre la Clean Architecture, une structure de packages claire est essentielle. Voici une approche courante pour un projet Spring Boot, illustrant comment Laty Gueye Samba aborde la séparation des préoccupations.

La Couche Domaine (Entities & Use Cases)

Cette couche est le cœur de l'application et doit être exempte de toute dépendance Spring Boot ou infrastructurelle. Elle contient les entités métier et les interfaces de cas d'utilisation (ports primaires).

// src/main/java/com/laty/project/domain/model/User.java
package com.laty.project.domain.model;

import java.util.Objects;

public class User {
    private Long id;
    private String username;
    private String email;

    // Constructeur, getters, setters
    public User(Long id, String username, String email) {
        this.id = id;
        this.username = username;
        this.email = email;
    }

    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }
    public String getUsername() { return username; }
    public void setUsername(String username) { this.username = username; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }

    // Logique métier potentielle
    public boolean isValidEmail() {
        return email != null && email.contains("@");
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        User user = (User) o;
        return Objects.equals(id, user.id);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id);
    }
}
    

Les cas d'utilisation définissent les actions que l'application peut effectuer, agissant comme des orchestrateurs de la logique métier. Ils dépendent des entités et définissent des interfaces (ports secondaires) pour interagir avec la persistance ou d'autres services externes.

// src/main/java/com/laty/project/domain/port/in/CreateUserUseCase.java
package com.laty.project.domain.port.in;

import com.laty.project.domain.model.User;

public interface CreateUserUseCase {
    User createUser(User user);
}

// src/main/java/com/laty/project/domain/port/out/UserRepositoryPort.java
package com.laty.project.domain.port.out;

import com.laty.project.domain.model.User;
import java.util.Optional;

public interface UserRepositoryPort {
    User save(User user);
    Optional<User> findByUsername(String username);
}
    

// src/main/java/com/laty/project/application/service/CreateUserService.java
package com.laty.project.application.service;

import com.laty.project.domain.model.User;
import com.laty.project.domain.port.in.CreateUserUseCase;
import com.laty.project.domain.port.out.UserRepositoryPort;

// Cette implémentation se trouve dans la couche application
// elle dépend des ports définis dans le domaine.
public class CreateUserService implements CreateUserUseCase {

    private final UserRepositoryPort userRepositoryPort;

    public CreateUserService(UserRepositoryPort userRepositoryPort) {
        this.userRepositoryPort = userRepositoryPort;
    }

    @Override
    public User createUser(User user) {
        // Logique métier spécifique : validation, etc.
        if (!user.isValidEmail()) {
            throw new IllegalArgumentException("Invalid email format");
        }
        // Vérification d'existence
        if (userRepositoryPort.findByUsername(user.getUsername()).isPresent()) {
            throw new IllegalArgumentException("Username already exists");
        }
        return userRepositoryPort.save(user);
    }
}
    

La Couche Infrastructure (Frameworks & Drivers)

C'est ici que Spring Boot et les technologies d'infrastructure (bases de données, serveurs web, etc.) entrent en jeu. Cette couche implémente les ports définis dans la couche Domaine/Application.

// src/main/java/com/laty/project/infrastructure/adapter/UserRepositorySpringJpaAdapter.java
package com.laty.project.infrastructure.adapter;

import com.laty.project.domain.model.User;
import com.laty.project.domain.port.out.UserRepositoryPort;
import com.laty.project.infrastructure.repository.SpringDataUserRepository;
import com.laty.project.infrastructure.entity.UserJpaEntity; // Une entité JPA spécifique

import org.springframework.stereotype.Component;
import java.util.Optional;

@Component
public class UserRepositorySpringJpaAdapter implements UserRepositoryPort {

    private final SpringDataUserRepository springDataUserRepository;

    public UserRepositorySpringJpaAdapter(SpringDataUserRepository springDataUserRepository) {
        this.springDataUserRepository = springDataUserRepository;
    }

    @Override
    public User save(User user) {
        UserJpaEntity userJpaEntity = UserJpaEntity.fromDomain(user); // Mapper domaine vers JPA
        UserJpaEntity savedEntity = springDataUserRepository.save(userJpaEntity);
        return savedEntity.toDomain(); // Mapper JPA vers domaine
    }

    @Override
    public Optional<User> findByUsername(String username) {
        return springDataUserRepository.findByUsername(username)
                .map(UserJpaEntity::toDomain);
    }
}
    

// src/main/java/com/laty/project/infrastructure/controller/UserController.java
package com.laty.project.infrastructure.controller;

import com.laty.project.domain.model.User;
import com.laty.project.domain.port.in.CreateUserUseCase;
import com.laty.project.infrastructure.dto.UserRequest;
import com.laty.project.infrastructure.dto.UserResponse;

import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/users")
public class UserController {

    private final CreateUserUseCase createUserUseCase;

    // Spring injecte l'implémentation de CreateUserUseCase (CreateUserService)
    public UserController(CreateUserUseCase createUserUseCase) {
        this.createUserUseCase = createUserUseCase;
    }

    @PostMapping
    public ResponseEntity<UserResponse> createUser(@RequestBody UserRequest request) {
        User userToCreate = request.toDomain(); // Mapper DTO vers domaine
        User createdUser = createUserUseCase.createUser(userToCreate);
        return new ResponseEntity<>(UserResponse.fromDomain(createdUser), HttpStatus.CREATED); // Mapper domaine vers DTO
    }
}
    

Avantages pratiques et défis d'implémentation

L'adoption de la Clean Architecture, même dans un projet Spring Boot monolithique, apporte des avantages significatifs. Le Développeur Full Stack Laty Gueye Samba a souvent observé ces bénéfices dans des applications métier complexes :

• Maintenabilité accrue : La logique métier est isolée, ce qui facilite les modifications sans impacter d'autres couches.
• Testabilité élevée : Les cas d'utilisation et les entités peuvent être testés de manière unitaire sans avoir à initialiser la base de données ou le serveur web.
• Indépendance technologique : Il est plus facile de changer de base de données, de framework web ou même d'interface utilisateur sans réécrire la logique métier.
• Développement piloté par le domaine : Favorise une meilleure compréhension et modélisation du domaine métier.

Cependant, des défis existent. L'investissement initial en temps pour structurer le projet et comprendre les principes peut être plus élevé. Il est également crucial de ne pas sur-ingénieriser des applications très simples où les avantages de la Clean Architecture pourraient ne pas justifier la complexité ajoutée. Une application de gestion de stock simple ne nécessitera peut-être pas le même niveau de formalisme qu'un système ERP ou une application de gestion hospitalière complexe.

Conclusion

L'implémentation de la Clean Architecture dans un projet Spring Boot monolithique est une stratégie puissante pour construire des applications résilientes, maintenables et testables. En adoptant cette approche, un développeur Full Stack Java Spring Boot + Angular comme Laty Gueye Samba s'assure que le code métier reste pur et indépendant, protégeant ainsi l'investissement logiciel sur le long terme. C'est une démarche d'architecture logicielle qui prépare le terrain pour l'avenir, que ce soit pour une simple évolution ou une refactorisation majeure.

Pour approfondir ce sujet et découvrir d'autres pratiques d'architecture et de développement, il est recommandé de consulter les ressources officielles et les ouvrages de référence sur la Clean Architecture et Spring Boot.

Ressources

• The Clean Architecture par Robert C. Martin
• Documentation officielle Spring Boot