GoMind

ARTICLE

Software Craftsmanship : l’apport de l’architecture hexagonale

L’architecture hexagonale, s’impose de plus en plus comme un standard. Elle répond aux problématiques de maintenabilité et de testabilité. Mais sa valeur est encore plus forte lorsqu’elle s’inscrit dans une démarche de Software Craftsmanship.

Chez GoMind, nous défendons une vision où le code n’est pas seulement fonctionnel, mais aussi durable. C’est une alliance de bonnes pratiques qui permet de livrer des logiciels de haute qualité, capables d’évoluer avec les besoins métier.

Qu’est-ce que l’architecture hexagonale ?

L’architecture hexagonale, introduite par Alistair Cockburn, vise à séparer le cœur métier d’une application de ses dépendances externes. L’idée est simple : le domaine (les règles métier) est indépendant des frameworks, bases de données ou interfaces utilisateurs.

En pratique, cette séparation s’organise autour de deux types de composants :

– Les ports, qui définissent les points d’entrée et de sortie du système.
– Les adapters qui connectent ces ports aux technologies concrètes (API, base de données, UI, etc.).

Prenons un exemple concret : une application e-commerce. Le cœur métier gère les règles de facturation ou de réduction. Que la commande arrive d’une API REST, d’une interface mobile ou d’un batch, peu importe. Les règles sont isolées. Cela permet de changer l’interface ou la base de données sans réécrire la logique métier.

Cette approche réduit considérablement la dette technique. Selon un rapport de McKinsey publié en 2020, près de 60 % du budget IT annuel des grandes entreprises est consacré à la gestion du code legacy et de la dette technique. En adoptant une architecture hexagonale, une partie importante de ce coût peut être économisée grâce à la flexibilité et la maintenabilité du code.

Si vous souhaitez savoir comment réduire votre dette technique grâce au Clean Code, nous avons rédigé un article à ce sujet.

Software Craftsmanship : la qualité comme culture

Le Software Craftsmanship repose sur un manifeste clair : livrer non seulement du logiciel qui fonctionne, mais aussi du logiciel bien conçu. Cela implique des pratiques comme le TDD (Test Driven Development), le refactoring continu, et le respect des principes SOLID.

Cette philosophie place le développeur dans une posture d’artisan. Comme un artisan du bois qui choisit les bons outils pour produire une œuvre durable, le développeur s’assure que chaque ligne de code reste lisible, maintenable et extensible.

En combinant craftsmanship et architecture hexagonale, les équipes garantissent que la qualité du code n’est pas une option. Elle devient une exigence. Pour un CTO ou un DSI, cela se traduit par des projets plus fiables, des délais respectés et un budget mieux maîtrisé.

Exemple concret : mettre en place une architecture hexagonale

Exemple Node.JS / TypeScript

1. Le domaine

				
					export class Order {
  constructor(public id: string, public amount: number) {}

  isValid(): boolean {
    return this.amount > 0;
  }
}
				
			

2. Le port

				
					export interface OrderRepository {
  save(order: Order): Promise<void>;
  findById(id: string): Promise<Order | null>;
}

				
			

3. L’adapter (MongoDB par exemple) :

				
					import { Order, OrderRepository } from './domain/Order';
import { Collection } from 'mongodb';

export class MongoOrderRepository implements OrderRepository {
  constructor(private collection: Collection) {}

  async save(order: Order): Promise<void> {
    await this.collection.insertOne({ id: order.id, amount: order.amount });
  }

  async findById(id: string): Promise<Order | null> {
    const result = await this.collection.findOne({ id });
    return result ? new Order(result.id, result.amount) : null;
  }
}
				
			

4. Le service métier avec TDD :

				
					import { Order } from './domain/Order';
import { OrderRepository } from './domain/OrderRepository';

export class OrderService {
  constructor(private repository: OrderRepository) {}

  async processOrder(order: Order): Promise<void> {
    if (order.isValid()) {
      await this.repository.save(order);
    }
  }
}
				
			
Ici encore, la logique métier reste indépendante de la technologie. On peut tester l’OrderService en injectant un faux repository (mock).

L’alliance entre hexagonal et craftsmanship : un levier stratégique

Testabilité accrue : l’architecture hexagonale rend les tests unitaires et d’intégration plus simples. Le TDD, cher au craftsmanship, en devient naturel.
Flexibilité technologique : changer de base de données ou de framework devient possible sans réécrire l’application. Cela réduit le risque de verrouillage technologique.
Durabilité : en réduisant la dette technique, les équipes livrent des applications qui tiennent dans le temps.
Clarté pour les équipes : un code structuré selon ces principes facilite l’onboarding des nouveaux développeurs et limite les bugs.

Un choix technique et stratégique

Le Numérique Responsable est au cœur de nos pratiques. Trop souvent oublié, il se trouve pourtant renforcé par l’usage conjoint de l’hexagonal et du craftsmanship.

Pourquoi ? Parce qu’un code clair et bien testé consomme moins de ressources à long terme. Les optimisations sont plus faciles, les déploiements plus sûrs, et les erreurs moins fréquentes. Selon l’Ademe, un serveur mal optimisé peut consommer jusqu’à 20 % d’énergie supplémentaire. En soignant l’architecture et la qualité, on réduit cet impact.

C’est là que se joue la différence : le choix d’une architecture n’est pas seulement technique, il est aussi éthique.

Adopter une architecture hexagonale n’est pas une mode. C’est une réponse aux enjeux réels de maintenabilité, de performance et de responsabilité. En la combinant au Software Craftsmanship, les entreprises s’assurent de bâtir des solutions robustes, évolutives et durables.