Transactions et architecture hexagonale avec Spring Boot

• 📅 30 août 2023
• 🏷️ Architecture
• 🏷️ Architecture Hexagonale
• 🏷️ Java
• 🏷️ Spring Boot
• 🏷️ Transactions
• 🏷️ Mockito

Introduction #

Dans l'article du mois dernier, je parle de l’architecture hexagonale et du talk qui m’a paru le plus intéressant sur le sujet. Toutefois, un des problèmes récurrents au sein des applications n’est pas abordé dans ce talk: la gestion transactionnelle d’un ensemble d’opérations.

Dans cet article, je vais vous proposer une solution possible pour assurer la réalisation de plusieurs opérations BDD de façon transactionnelle tout en respectant les fondamentaux de l’architecture hexagonale c’est à dire de ne pas intégrer d’éléments de framework dans notre domaine métier.

Le cas d’usage #

Pour illustrer mes propos, je vais utiliser un cas d’usage classique qui est le transfert d’argent entre deux comptes bancaires. L’argent va d’abord être retiré du compte A puis sera ensuite ajouté au compte B. Les deux opérations doivent être réalisées avec succès pour que la transaction soit commitée. Si une erreur survient pendant la transaction, elle doit être rollbackée pour assurer l’intégrité des données.

Le domaine & l’infrastructure #

L’objet de cet article n’est pas de refaire une explication de l’architecture hexagonale:

• Je n’irai donc pas dans le détail de l’implémentation du domaine et de l’infrastructure mais vous pouvez vous y plonger en récupérant le code source complet. Si vous cherchez à comprendre les bases de l’architecture hexagonale avec un exemple concret d’implémentation utilisant Spring Boot, je vous invite encore une fois à regarder cet excellent talk sur YouTube.
• J’ai choisi de simplifier le domaine au maximum: on pourrait, par exemple, imaginer l’usage de value objects pour les montants de façon à gérer la devise. Mais ça ne sera pas le cas dans cet exemple 😉

Simuler une erreur et tester le rollback #

Avant de nous lancer dans l’implémentation de la gestion transactionnelle, nous allons préparer le test qui nous permettra de valider que le rollback a bien eu lieu.

Pour ce faire, nous allons mocker notre repository pour déclencher une erreur (RuntimeException) lors de la sauvegarde. Nous allons également préciser que nous voulons appliquer ce mock uniquement si le compte concerné par la sauvegarde est le compte de destination. Nous pourrons ainsi contrôler que le rollback a eu lieu en vérifiant que le compte source, pour lequel le save a eu lieu sans erreur, a gardé sa balance d’origine.

@Test
public void whenPostTransfer_andError_thenStatus500_andProblemDetail_andRollback() throws Exception {
	Account sourceAccount = accountManager.openAccount(BigDecimal.valueOf(2000));
	Account destinationAccount = accountManager.openAccount(BigDecimal.valueOf(1000));

	// Simulate a RuntimeException while saving destination account
	when(accountsRepository.save(
			argThat(new AccountIdArgumentMatcher(destinationAccount))))
			.thenThrow(new RuntimeException());

	// Assert that response is a ProblemDetail
	mockMvc.perform(post("/transfer")
					.contentType(MediaType.APPLICATION_JSON)
					.content("{     \"amount\": \"500\"," +
							"    \"source\": \""+sourceAccount.id()+"\"," +
							"    \"destination\": \""+destinationAccount.id()+"\" }"))
			.andExpect(content().contentType(MediaType.APPLICATION_PROBLEM_JSON))
			.andExpect(status().is5xxServerError());

	// Assert that transaction has been rolled back
	assertThat(accountManager.viewAccount(sourceAccount.id()).balance())
			.isEqualByComparingTo(sourceAccount.balance());
}

Pour être capable d’identifier le compte concerné par le mock, nous utilisons un ArgumentMatcher:

public class AccountIdArgumentMatcher implements ArgumentMatcher<Account> {
    private Account left;

    public AccountIdArgumentMatcher(Account left) {
        this.left = left;
    }

    @Override
    public boolean matches(Account right) {
        return left.id().equals(right.id());
    }

}

Implémenter la gestion transactionnelle #

Nous voici maintenant au coeur du problème: la mise en place de la transaction.

Dans l’idéal, nous aurions voulu positionner l’annotation @Transactional au niveau de la méthode transferMoney de la classe AccountService. Néanmoins, cette classe se situe dans la couche domaine. Pour respecter les principes de l’architecture hexagonale, nous ne voulons pas insérer d’éléments de framework dans cette couche.

Si vous avez suivi le talk dont je parle plus haut, vous vous souvenez de l’utilisation astucieuse de @ComponentScan pour injecter le @DomainService dans notre partie infrastructure. Est-ce qu’il existe une astuce du même type qui nous permettrait d’insérer l’annotation @Transactional au niveau de l’annotation @DomainService via le code de notre couche infrastructure? La réponse est oui: grace à AspectJ.

Pour commencer, nous devons écrire le code qui va permettre l’exécution au sein d’une transaction:

package dlemontagner.moneytransfer.infrastructure.configuration.transactional;

import org.springframework.transaction.annotation.Transactional;

import java.util.function.Supplier;

public class TransactionalExecutor {
    @Transactional
    <T> T executeInTransaction(Supplier<T> execution) {
        return execution.get();
    }
}

Ensuite, nous devons “capturer” les appels aux méthodes contenues dans les classes annotées @DomainService pour les exécuter via le TransactionalExecutor défini ci-dessus:

package dlemontagner.moneytransfer.infrastructure.configuration.transactional;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class TransactionalDomainServiceAspect {
    private final TransactionalExecutor transactionalExecutor;

    public TransactionalDomainServiceAspect(TransactionalExecutor transactionalExecutor) {
        this.transactionalExecutor = transactionalExecutor;
    }

    @Pointcut("@within(ddd.DomainService)")
    private void withinDomainService() {

    }

    @Around("withinDomainService()")
    private Object domainService(ProceedingJoinPoint proceedingJoinPoint) {
        return transactionalExecutor.executeInTransaction(() -> {
            try {
                return proceedingJoinPoint.proceed();
            } catch (Throwable e) {
                throw new RuntimeException(e);
            }
        });
    }

}

A noter que, si vous le souhaitez, il est possible d’utiliser TransactionTemplate au lieu de notre TransactionalExecutor.

Pour terminer, nous devons créer la configuration qui permettra d’activer TransactionalDomainServiceAspect & TransactionalExecutor au sein de notre infrastructure:

package dlemontagner.moneytransfer.infrastructure.configuration.transactional;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.EnableAspectJAutoProxy;

@Configuration
@EnableAspectJAutoProxy
public class TransactionalConfiguration {
    @Bean
    TransactionalDomainServiceAspect transactionalDomainServiceAspect(TransactionalExecutor transactionalExecutor) {
        return new TransactionalDomainServiceAspect(transactionalExecutor);
    }

    @Bean
    TransactionalExecutor transactionalExecutor() {
        return new TransactionalExecutor();
    }
}

Suite à cela, notre test whenPostTransfer_andError_thenStatus500_andProblemDetail_andRollback doit passer au vert ✅ 🙂

Le code source #

Retrouvez l'intégralité du code source dans ce repository.

Conclusion #

Comme nous pouvons le constater, garder une couche domaine sans dépendance au framework technique constitue une contrainte importante et qu’il ne faut pas négliger lorsque l’on choisit d’adopter une architecture hexagonale. Pour la respecter, il faudra parfois faire preuve d’astuce et ceci peut compliquer le développement initial ainsi que l’appréhension du code par les nouveaux venus sur le projet.

AspectJ nous a permis de répondre à notre problématique de transactions mais je pense que cette solution est à garder en tête pour d’autres situations nécessitant d’englober, via la couche infrastructure, des implémentations techniques autour d’éléments de la couche domaine.

Enfin, pour faire le lien avec l’article du mois dernier, vous vous demandez peut être si cette méthode est applicable à Quarkus. AspectJ n’est pas utilisé par Quarkus, il faudra donc se tourner vers d’autres solutions. Je n’ai pas encore creusé le sujet mais il est probable que l’écriture d’une extension soit nécessaire comme ce fut le cas pour l’injection des @DomainService. Peut-être l’objet d’un prochain article? 😉

• Précédent: Architecture Hexagonale, de Spring Boot à Quarkus
• Suivant: Renforcer la résilience grâce au pattern Circuit Breaker