Clean Architecture

Archi & techno

Architecture Hexagonale & Clean architecture : bonnet blanc, blanc bonnet ? – Compte-rendu du talk de Christophe Breheret-Girardin du Comptoir x La Duck Conf 2023

icon de pizza comme une representation de clean archi

Afin de pallier aux problèmes des architectures N-tiers, plusieurs alternatives ont émergé après les années 2000, dont l’architecture Hexagonale et la Clean architecture. Seulement, elles ne sont pas toujours bien comprises : pour expliquer l'une, certains utilisent parfois les termes de l'autre ; d’autres se basent sur des croyances plutôt que sur les publications d'origine. Et si nous comparions ces deux architectures pour lever le doute une fois pour toutes ? Les concepts d’architecture hexagonale et de clean architecture sont parfois mélangés ou mal compris.…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests bout en bout et autres

Introduction L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Nous avons pu voir dans les autres articles de la série différents types de tests. Certains nous aidant à vérifier les règles métier comme les tests unitaires : Un test peut en cacher un autre - tests unitaires - partie 1 Un test…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests d’acceptation

Introduction L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Deux phrases extraites de l’article de Ian Cooper avaient retenu l’attention : “Le code issu d’un refactoring ne requiert pas de faire de nouveaux tests dessus !” “Je vous recommande d’utiliser ports/adaptateurs et d’écrire les tests en outside-in depuis le use case.” Nous…

Lire la suite
Software Craftsmanship

Application / Domain / Infrastructure : des mots de la Layered Hexagonal Clean Architecture ?

Depuis quelques années, quand je découvre un projet je vois régulièrement des répertoires qui s'appellent : - Application - Domain - Infrastructure D'où viennent ces mots ? Quel intérêt à les utiliser ou ne pas les utiliser aujourd'hui ? Je me suis documenté sur le sujet et je vous propose un voyage dans le temps pour y voir un peu plus clair.

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests d’intégration – P1

Introduction L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Nous avons pu voir dans ces articles autour des tests unitaires :  Un test peut en cacher un autre — Tests unitaires — P1 Un test peut en cacher un autre — Tests unitaires — P2 Que ces tests sont exclusivement centrés sur…

Lire la suite
Bonne pratique

Property-based testing : Un contrat d’interface en béton

La compréhension de cet article est facilitée par des connaissances sur l'architecture hexagonale (Clean Archi) et le Domain-Driven Design. Lorsque vous développez un produit en vous basant sur les principes du Domain-Driven Design (DDD) et que vous vous efforcez de respecter les principes de Clean Archi, vous vous retrouvez alors probablement avec une catégorie particulière d'interfaces appelées Repository. Nous allons voir ici qu'une stratégie de test des implémentations se reposant uniquement sur les méthodes de l'interface peut s'avérer très utile pour itérer sur notre implémentation sans influencer notre code métier. Nous allons…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests d’intégration – P2

Introduction L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Nous avons pu voir dans ces articles autour des tests unitaires :  Un test peut en cacher un autre — Tests unitaires — P1 Un test peut en cacher un autre — Tests unitaires — P2 Que ces tests sont exclusivement centrés sur…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests unitaires – P2

Introduction L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Deux phrases extraites de l’article de Ian Cooper ont été mises en avant : “Le code issu d’un refactoring ne requiert pas de nouveaux tests” “Je vous recommande d’utiliser ports/adaptateurs et d’écrire les tests en outside-in depuis le use case” Ces deux axes…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Tests unitaires – P1

Introduction L’article d’introduction débute en listant certaines différences entre ma vision en terme d’architecture applicative ou encore de rédaction des tests, que je peux avoir avec d’autres développeurs. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment. Deux phrases extraites de l’article de Ian Cooper ont été mises en avant : “Le code issu d’un refactoring ne requiert pas de nouveaux tests” “Je vous recommande d’utiliser ports/adaptateurs et d’écrire les tests en outside-in depuis le use case” Ces…

Lire la suite
Software Craftsmanship

Un test peut en cacher un autre – Un peu de théorie

Introduction En discutant avec des développeurs, je remarque plusieurs choses : Nos approches sur l’architecture applicative du code sont différentes Les définitions que nous donnons aux catégories de tests sont différentes Les façons de rédiger les tests sont différentes Sans généraliser, je pense qu'il est parfois difficile dans ce contexte d'identifier précisément quoi tester et comment. Être au clair sur ces trois points me semble important et permet de me faciliter la vie et d'être plus confiant au quotidien, laissant beaucoup moins de place à…

Lire la suite