Tutoriel Go

Architecture hexagonale Go : Ports et Adapters maîtrisés

Lorsque vous travaillez sur des applications Go de plus grande envergure, la maintenance et l’évolutivité deviennent des enjeux majeurs. C’est là qu’intervient l’architecture hexagonale Go. Ce pattern de conception n’est pas un outil Go spécifique, mais une méthodologie visant à encapsuler la logique métier (le cœur de l’application) pour qu’elle soit totalement indépendante des détails techniques externes, tels que les bases de données, les services HTTP ou les systèmes de messagerie. Il s’agit d’une approche cruciale pour séparer les préoccupations et rendre votre code robuste face aux changements technologiques.

L’objectif principal est de forcer le développement de la couche métier à dépendre uniquement d’interfaces (les « Ports ») plutôt que de structures concrètes (les « Adapters »). En maîtrisant l’architecture hexagonale Go, vous transformez votre code Go en un système modulaire, facile à tester avec des mocks, et adaptable à toute technologie future. Nous allons voir comment le concept de Ports et Adapters, historiquement promu par Alistair Cockburn, trouve une implémentation idiomatique et élégante dans l’écosystème Go.

Pour ce guide approfondi, nous allons d’abord décortiquer les principes théoriques qui régissent l’architecture hexagonale. Ensuite, nous verrons une implémentation concrète en Go avec deux exemples de code pour illustrer le pattern. Nous approfondirons les cas d’usage avancés pour l’intégration de systèmes externes, nous aborderons les erreurs courantes et conclurons par les meilleures pratiques pour garantir la pérennité de vos microservices Go.

🛠️ Prérequis

Pour suivre ce tutoriel de haut niveau sur l’architecture hexagonale Go, certains prérequis techniques sont recommandés pour vous assurer de comprendre les subtilités du design pattern.

Connaissances requises

Go Idiomatic Development : Une bonne compréhension du style Go, notamment l’utilisation des interfaces (qui sont au cœur du pattern).
OOP/Design Patterns : Familiarité avec les concepts de séparation des préoccupations (SoC), l’injection de dépendances (DI) et le principe d’inversion de dépendance (DIP).
Systèmes distribués : Une idée de ce qu’impliquent les I/O externes (API REST, bases de données relationnelles, etc.).

Niveau de Langage : Il est crucial de travailler avec Go 1.18 ou supérieur pour bénéficier pleinement des fonctionnalités modernes et de la meilleure gestion des packages. Nous recommandons l’utilisation de modules Go pour gérer les dépendances de manière propre.

Installation et configuration

Go : Assurez-vous d’avoir Go installé via le gestionnaire officiel : go version.
Gestionnaire de dépendances : Nous utiliserons nativement le système de modules Go : go mod init mon_app.
Test Tools : Bien que non obligatoire, avoir un outil de mocking pour les tests unitaires est fortement conseillé (ex: gomock).

Ces prérequis assurent que vous êtes prêt à plonger dans la théorie et la pratique de la séparation des couches métier avec l’architecture hexagonale Go.

📚 Comprendre architecture hexagonale Go

Le concept fondamental de l’architecture hexagonale, ou Ports et Adapters, repose sur l’idée que l’application métier (le « cœur » ou le « domaine ») ne doit jamais savoir comment il est appelé ou avec quoi il parle. Il doit seulement déclarer ce dont il a besoin. C’est une application directe du Principe d’Inversion de Dépendance (DIP). L’analogie la plus simple est celle d’une machine à café. Le cœur métier (le concept de « café parfait ») est indépendant de savoir s’il est branché sur une prise électrique standard, une batterie portable ou un générateur. Ce qui compte, c’est le port (la prise) qui définit l’interface minimale nécessaire pour fonctionner.

Ports et Adapters : Le cœur théorique

Dans le contexte Go, les « Ports » sont des interfaces Go. Elles définissent le contrat (les méthodes) que le cœur de l’application (le cas d’usage, ou Use Case) attend des systèmes externes. Le « cœur » appelle ces interfaces sans savoir qui les implémentera. Les « Adapters », eux, sont les implémentations concrètes de ces ports. Ce sont les adaptateurs qui s’occupent des détails spécifiques : parler à une base de données PostgreSQL, gérer les requêtes HTTP ou interagir avec Kafka.

Schéma de dépendance

Imaginez ce schéma :

        +-------------------+
        |  COUCHE DOMAINE    | (Le coeur métier, ne dépend de rien)
        +---------+---------+
                  |
                  V
        +-------------------+
        | PORT (Interface)  | (Ex: UserRepository)
        +---------+---------+
                  ^ ^
                  | |
          (Implémente) (Utilisé par)
                  | |
        +-------------------+
        | ADAPTER (Implémentation) | (Ex: PostgresAdapter)
        +--------------------------+

Cette séparation garantit que si vous décidez de passer de MySQL à MongoDB, vous ne modifiez que l’Adapter (PostgresAdapter devient MongoAdapter), sans toucher ni au Core, ni aux Ports. C’est la force majeure de l’architecture hexagonale Go. Comparativement à des architectures monolithiques où les couches sont souvent mélangées, ce pattern impose une stricte séparation des responsabilités. En Go, cela se traduit par la Déclaration d’Intentions via les interfaces, qui sont naturellement valorisées dans l’écosystème Go.

L’utilisation de l’architecture hexagonale Go n’est pas seulement un choix architectural, c’est une garantie de testabilité. En testant un cas d’usage, vous n’avez pas besoin de démarrer une vraie base de données ; vous pouvez simplement fournir un « Mock Adapter » qui implémente le Port, permettant des tests unitaires ultra-rapides et fiables. Cette capacité à isoler les composants est la plus grande valeur ajoutée de ce pattern en Go.

🐹 Le code — architecture hexagonale Go

package main

import (
	"fmt"
	"errors"
)

// 1. DEFINITION DU PORT (Interface)
// Le Port définit le contrat que le cas d'usage attend du dépôt de données.
type UserRepositoryPort interface {
	Save(user User) error
	FindByID(id string) (User, error)
}

type User struct {
	ID string
	Email string
}

// 2. CAS D'USAGE (Use Case - Le coeur métier)
// Ce module dépend uniquement de l'interface UserRepositoryPort.
type UserService struct {
	UserRepo UserRepositoryPort
}

func NewUserService(repo UserRepositoryPort) *UserService {
	return &UserService{UserRepo: repo}
}

// Création d'un utilisateur : Logique métier pure, ne connaît rien de la DB.
func (s *UserService) CreateUser(user User) (User, error) {
	if user.Email == "" {
		return User{}, errors.New("email requis")
	}
	// Ici, on pourrait ajouter des validations métiers complexes

	// Appel au Port pour sauvegarder les données.
	err := s.UserRepo.Save(user)
	if err != nil {
		return User{}, fmt.Errorf("erreur de sauvegarde : %w", err)
	}
	
	// On pourrait récupérer l'objet sauvegardé pour confirmation
	userFound, _ := s.UserRepo.FindByID(user.ID)
	return userFound, nil
}

// 3. ADAPTER (Implémentation concrète de la DB)
// Cet Adapter implémente le Port (UserRepositoryPort) pour PostgreSQL.
type PostgresAdapter struct{} 

func NewPostgresAdapter() *PostgresAdapter {
	return &PostgresAdapter{}
}

func (p *PostgresAdapter) Save(user User) error {
	fmt.Printf("--> [PostgresAdapter] Sauvegarde réussie de l'utilisateur %s dans la DB.
", user.ID)
	// Simulation de la connexion réelle à la base de données ici
	return nil
}

func (p *PostgresAdapter) FindByID(id string) (User, error) {
	fmt.Printf("--> [PostgresAdapter] Récupération de l'utilisateur %s depuis la DB.
", id)
	// Simulation d'une requête réussie
	return User{ID: id, Email: "test@example.com"}, nil
}

func main() {
	// 1. Initialisation de l'Adapter (l'implémentation réelle)
	postgresAdapter := NewPostgresAdapter()

	// 2. Injection de la dépendance (Adapter est passé comme implémentation du Port)
	userService := NewUserService(postgresAdapter)

	// 3. Utilisation du Cas d'Usage (le coeur métier n'a jamais vu le type PostgresAdapter)
	newUser := User{ID: "u123", Email: "new@example.com"}
	user, err := userService.CreateUser(newUser)

	if err != nil {
		fmt.Println("Erreur lors de la création :", err)
	}

	if user.ID != "" {
		fmt.Printf("Succès ! Utilisateur traité : %s
", user.Email)
	}
}

📖 Explication détaillée

Ce premier snippet Go est l’illustration parfaite du pattern Ports et Adapters. Il montre comment la logique métier est isolée du mécanisme de persistance. Analysons chaque bloc pour comprendre la puissance de cette approche.

Le rôle de l’interface comme Port (Ports/Adapter Ports)

Le bloc type UserRepositoryPort interface {...} est fondamental. Ce n’est pas une implémentation de base de données ; c’est un contrat. En définissant cette interface, nous déclarons le « Port » : l’interface métier pour l’accès aux utilisateurs. Le cas d’usage, UserService, ne dépend pas de PostgresAdapter, mais seulement de UserRepositoryPort. C’est l’application du DIP : les dépendances sont inversées du module de haut niveau (Use Case) vers l’interface de bas niveau (Port).

Cette approche est la pierre angulaire de l’architecture hexagonale Go, car elle garantit que si vous changez de base de données, le code du UserService n’aura absolument aucun changement. Il est agnostique par conception. L’interface est la frontière mouvante qui protège le cœur.

Le cas d’usage : le cœur métier (Use Case)

Le UserService contient la logique métier pure. Regardez la méthode CreateUser. Elle vérifie l’email, elle orchestre la sauvegarde, et elle gère les erreurs. Remarquez qu’il n’y a aucune ligne de code qui ressemble à un appel SQL (SELECT, INSERT, etc.). Il appelle simplement s.UserRepo.Save(user). Pour un développeur non averti, cela pourrait sembler être une simple appel de fonction ; en réalité, c’est une délimitation stricte de responsabilité. Le UserService ne s’occupe que de la *séquence* métier, laissant les détails de *comment* sauvegarder à l’Adapter.

L’Adapter (PostgresAdapter)

Le PostgresAdapter est l’implémentation concrète, l’adaptateur. Il est le seul endroit du code qui « saigne » la technologie de la base de données. Il implémente UserRepositoryPort, signifiant qu’il respecte le contrat défini par le Port. Dans la vie réelle, ce struct deviendrait plus complexe, gérant les connexions BDD, les transactions et le mapping des erreurs spécifiques à PostgreSQL. L’injection de ce PostgresAdapter dans le UserService via la fonction NewUserService est l’acte de liaison qui permet à l’application de démarrer. C’est le point clé de la testabilité : lors des tests, nous injecterons un « Fake Adapter » pour ne jamais toucher à une vraie base de données. Le strict respect de l’interface est la clé de cette isolation. L’architecture hexagonale Go est donc parfaitement supportée par le mécanisme d’interfaces de Go.

📖 Ressource officielle : Documentation Go — architecture hexagonale Go

🔄 Second exemple — architecture hexagonale Go

package main

import (
	"fmt"
)

// Cas d'usage avancé : Exposer la fonction via une API HTTP (un Adapter différent)
// L'adapter HTTP utilise le même Port mais d'une manière différente.
type HTTPUserHandler struct {
	UserService *UserService
}

func NewHTTPUserHandler(userService *UserService) *HTTPUserHandler {
	return &HTTPUserHandler{UserService: userService}
}

// Simule la gestion d'une requête HTTP POST /user
func (h *HTTPUserHandler) HandleCreateUserRequest(email string) {
	fmt.Println("--- Simulation Requête HTTP POST /user --- ")

	// 1. Mapping des données entrantes HTTP vers le Domain Model
	inputUser := User{ID: "api_user", Email: email}

	// 2. Exécution du cas d'usage via l'injection de dépendance
	_, err := h.UserService.CreateUser(inputUser)

	// 3. Gestion de la réponse HTTP (adaptateur de sortie)
	if err != nil {
		fmt.Printf("HTTP 400 Bad Request : %s\n", err.Error())
	} else {
		fmt.Println("HTTP 201 Created : Utilisateur créé avec succès.")
	}
}

func main() {
	// Simulation complète : Adapter HTTP -> Use Case -> Port -> Adapter DB
	postgresAdapter := NewPostgresAdapter()
	userService := NewUserService(postgresAdapter)
	httpHandler := NewHTTPUserHandler(userService)
	httpHandler.HandleCreateUserRequest("api.user@corp.com")
}

▶️ Exemple d’utilisation

Imaginons le scénario où nous construisons le service d’inscription utilisateur. Notre objectif est que l’ajout d’une nouvelle base de données ou d’un nouveau fournisseur de messages ne nécessite aucune modification de la logique métier principale. Nous allons utiliser les snippets précédents pour démontrer l’exécution complète du flux.

Scénario : Un utilisateur tente de s’inscrire via notre API. L’API reçoit l’email, le transforme en objet métier, et exécute le cas d’usage de création d’utilisateur.

Appel du code (dans main) : postgresAdapter := NewPostgresAdapter() userService := NewUserService(postgresAdapter) newUser := User{ID: "u123", Email: "new@example.com"} user, err := userService.CreateUser(newUser)

Sortie console attendue :

--> [PostgresAdapter] Sauvegarde réussie de l'utilisateur u123 dans la DB.
--> [PostgresAdapter] Récupération de l'utilisateur u123 depuis la DB.
Succès ! Utilisateur traité : test@example.com

Explication de la sortie :

--> [PostgresAdapter] Sauvegarde... : Ceci montre l’exécution de l’Adapter de persistance. C’est le niveau technique qui gère le détail de la sauvegarde. Le UserService n’a jamais eu besoin de savoir qu’il y avait une « sauvegarde » ; il a juste appelé Save.
--> [PostgresAdapter] Récupération... : Ceci confirme que la méthode FindByID a été appelée pour compléter le cycle métier.
Succès ! Utilisateur traité : test@example.com : C’est la confirmation que le cœur métier (le UserService) a reçu les données du Port et a pu valider le cycle complet, indépendamment de la technologie utilisée par l’Adapter.

L’architecture hexagonale Go permet cette découplage élégant, garantissant que la couche présentation (l’API HTTP) et la couche persistance (PostgresAdapter) sont des ‘widgets’ qui se branchent sur le Port, sans jamais interférer avec le fonctionnement du Use Case.

🚀 Cas d’usage avancés

L’architecture hexagonale Go excelle à gérer l’intégration de services tiers. Voici plusieurs scénarios avancés où ce pattern devient indispensable pour la robustesse d’une application professionnelle.

1. Intégration avec une API REST Tiers (Adapter Externe)

Si votre service doit appeler un service externe (ex: Google Maps pour la géolocalisation), ce service tiers ne doit pas dépendre du cœur métier. Vous créez un Port LocationProviderPort qui définit GetCoordinates(address string) (Lat, Lng float64, error). L’Adapter GoogleMapsAdapter implémentera ce Port en faisant des appels HTTP spécifiques. Le Use Case appelle simplement locationPort.GetCoordinates(...), sans savoir si c’est Google, OpenStreetMap ou un mock de test.

Exemple de code d’utilisation du Port :


// Dans le cas d'usage
// locationPort.GetCoordinates(user.Address) 
// Le cas d'usage reste propre, peu importe la source des coordonnées.

2. Gestion Asynchrone par Message Queue (Message Adapter)

L’intégration de systèmes de messagerie comme Kafka ou RabbitMQ est un défi. On définit un Port de message, par exemple MessagePublisherPort avec la méthode Publish(topic string, data []byte) error. L’Adapter KafkaAdapter implémentera ce port en gérant les producteurs et les topics spécifiques à Kafka. Le cœur métier utilise alors le Port : messagePublisher.Publish("user.created", userJSON). Si demain vous passez de Kafka à RabbitMQ, vous changez uniquement l’adapter sans toucher à la logique de création d’utilisateur.

3. Persistance en Cache Distribué (Cache Adapter)

Les données de session ou les données souvent lues nécessitent un cache comme Redis. Au lieu de modifier l’Adapter BDD principal, vous créez un CachePort qui définit des méthodes GetCache(key string) (interface{}, error) et SetCache(key string, value interface{}, ttl time.Duration) error. Votre Use Case pourrait alors interagir avec cette couche de cache avant de solliciter la BDD principale, en utilisant le pattern « Cache-Aside ». C’est une optimisation de performance gérée par l’architecture hexagonale.

Exemple dans le Use Case :


// Tentative de lecture en cache
if data, err := cachePort.GetCache(key); err == nil {
    return data.(User)
}
// Si cache miss, lire depuis la BDD
user, err := userRepo.FindByID(id)
// Et potentiellement re-stager dans le cache pour la prochaine fois
cachePort.SetCache(key, user, 1*time.Hour)

4. Intégration de Services d’Authentification (Security Adapter)

Pour l’authentification, le Use Case ne doit pas contenir de logique de hachage de mot de passe ou de communication avec OAuth. Il reçoit un utilisateur déjà validé par un port AuthenticatorPort. Cet adaptateur pourrait implémenter la validation via un service OAuth externalisé. Le cœur métier ne dépend que de AuthUser (un simple struct) et de l’interface Authenticatable, garantissant une totale isolation de la couche sécurité des préoccupations de la logique métier.

⚠️ Erreurs courantes à éviter

Adopter l’architecture hexagonale Go est puissant, mais cela introduit de nouvelles complexités. Les développeurs peuvent tomber dans des pièges courants qui annulent les bénéfices du pattern.

1. Pollution du Domain Model par les types externes

L’erreur la plus fréquente est de laisser le modèle de données (Domain Model) contenir des champs spécifiques à l’infrastructure (ex: un champ DBID string ou HTTPStatus int). Le Domain Model doit être 100% pur et indépendant. Les adapter doivent s’occuper du mapping entre le modèle de données pur et les structures ORM/HTTP.

2. Dépendance directe de l’Use Case à l’Adapter

Si, par inadvertance, vous faites userService := NewUserService(postgresAdapter) au lieu de passer l’interface, votre Use Case dépend concrètement de PostgreSQL. Vous ne pourrez plus remplacer cet adapter sans refactorisation majeure. Toujours injecter le Port (l’interface), jamais l’implémentation concrète.

3. Négliger les Mocks pour les tests unitaires

Le principal avantage de ce pattern est la testabilité. Si vous testez le UserService en utilisant un vrai PostgresAdapter, votre test sera un test d’intégration lent et fragile. Il faut impérativement créer un *Mock Adapter* pour chaque test unitaire, qui implémente le Port sans rien faire de réel.

4. Gestion complexe des transactions distribuées

Lors de plusieurs appels d’Adapters (ex: BDD + Message Queue), il est facile de ne pas gérer correctement les transactions. Si l’Adapter BDD réussit, mais que l’Adapter Message Queue échoue, vous vous retrouvez avec des données incohérentes. Il faut implémenter une logique compensatoire (Saga Pattern) au niveau du Use Case pour maintenir la cohérence transactionnelle, même avec des systèmes asynchrones.

✔️ Bonnes pratiques

Pour maximiser les bénéfices de l’architecture hexagonale Go, suivez ces meilleures pratiques professionnelles.

1. Séparation stricte des Packages et des Dépendances

Structurez votre codebase en packages distincts (ex: domain, usecase, adapter/postgres, adapter/http). Le package domain ne doit dépendre que d’interfaces qu’il définit lui-même. Les packages d’Adapters doivent dépendre du package domain.

2. Définir les Ports au niveau du Domaine

Toutes les interfaces des Ports (ex: UserRepositoryPort) doivent résider dans le package domain ou ports. Cela garantit que tous les consommateurs du Port voient le même contrat et renforce le DIP. C’est le point de référence contractuel.

3. Propager le Contexte Go

Dans tous les Ports et Use Cases, passez toujours le context.Context en premier argument. Ceci est crucial pour la gestion des timeouts, des cancellations et du traçage (tracing) des requêtes à travers les multiples Adapters, améliorant la robustesse du système.

4. Valider les données dès le Domain Model

Les validations de données (présence de l’email, format de la date) doivent avoir lieu au niveau du Use Case (au début de la méthode) ou mieux, dans la structure de Données du Domaine elle-même (avec des méthodes de construction ou des New()). Les adapters doivent simplement faire passer les données brutes au Use Case, sans validation.

5. Regrouper les Adapters par Fonctionnalité

Au lieu d’avoir un grand dossier adapters/, groupez-les par fonctionnalité métier (ex: adapters/user/postgres.go, adapters/product/redis.go). Cela rend le système plus lisible et facilite l’ajout ou la suppression de sources de données spécifiques.

📌 Points clés à retenir

Le cœur de l'architecture hexagonale Go est l'interface Go (le Port), qui force le découplage du cas d'usage de son mécanisme d'appel.
Le cas d'usage ne doit dépendre que des Ports (interfaces), et non des Adapters concrets, respectant ainsi le DIP.
Les Adapters sont les implémentations concrètes qui encapsulent les technologies externes (Postgres, Kafka, HTTP) sans jamais polluer le domaine.
La testabilité est le bénéfice majeur : chaque Use Case peut être testé en injectant des Mocks qui implémentent les Ports, sans dépendre d'une infrastructure réelle.
Le 'Flux' des données est toujours : Client -> Adapter d'Entrée (HTTP) -> Cas d'Usage (Port) -> Adapter de Sortie (DB).
En Go, le mécanisme d'interfaces est le mécanisme idéal pour représenter les Ports et Adapter Ports de manière idiomatique.
La gestion des erreurs doit être robuste, en remontant toujours les erreurs de l'Adapter au niveau du Use Case pour une gestion métier appropriée.
Le Domain Model doit rester pur et ne connaître aucune technologie d'infrastructure.

📚 Articles liés

✅ Conclusion

Pour récapituler, l’architecture hexagonale Go est une démarche de pensée qui transforme un ensemble de fonctions Go en un véritable système modulaire et pérenne. Nous avons vu que ce pattern repose fondamentalement sur l’utilisation rigoureuse des interfaces Go pour définir des Ports de communication. En séparant votre logique métier (le Use Case) de sa persistance (l’Adapter), vous obtenez une robustesse inégalée face à l’évolution technologique, qu’il s’agisse de passer de MySQL à CockroachDB, ou de remplacer un appel HTTP par un message Kafka.

L’application de cette méthodologie, même sur des projets de petite taille, force une discipline de conception qui porte ses fruits à long terme. Ne considérez pas cette architecture comme une contrainte, mais comme un puissant levier de vélocité : elle vous permet d’innover sur les adapters sans risquer de casser le cœur métier. L’exemple du passage de la DB aux messages asynchrones montre que le coeur reste stable, tandis que les adapters (PostgresAdapter, KafkaAdapter) sont les composants interchangeables et isolés.

Pour aller plus loin, je vous encourage à implémenter un projet réel en suivant ce pattern, en commençant par un simple CRUD et en y ajoutant progressivement un canal de communication asynchrone (comme un Adapter RabbitMQ). Des ressources comme les conférences Go ou des articles de Martin Fowler sur le Domain-Driven Design sont excellentes pour approfondir ce sujet. N’hésitez pas à pratiquer avec des Mocks pour chaque Use Case afin de solidifier votre maîtrise de l’architecture hexagonale Go.

N’oubliez jamais que le code est un reflet des limites humaines. Adopter le pattern Hexagonal, c’est se donner les meilleurs outils pour gérer la complexité et écrire du code que des développeurs de demain pourront comprendre et maintenir. Vous avez maintenant les fondations pour architecturer des systèmes Go de niveau industriel. Testez ces concepts dans vos propres projets et partagez vos découvertes ! Pour en savoir plus sur les fondations de Go, consultez la documentation Go officielle. Bonne programmation !

Architecture hexagonale Go : Ports et Adapters maîtrisés

Architecture hexagonale Go : Ports et Adapters maîtrisés

🛠️ Prérequis

Connaissances requises

Installation et configuration

📚 Comprendre architecture hexagonale Go

Ports et Adapters : Le cœur théorique

Schéma de dépendance

🐹 Le code — architecture hexagonale Go

📖 Explication détaillée

Le rôle de l’interface comme Port (Ports/Adapter Ports)

Le cas d’usage : le cœur métier (Use Case)

L’Adapter (PostgresAdapter)

🔄 Second exemple — architecture hexagonale Go

▶️ Exemple d’utilisation

🚀 Cas d’usage avancés

1. Intégration avec une API REST Tiers (Adapter Externe)

2. Gestion Asynchrone par Message Queue (Message Adapter)

3. Persistance en Cache Distribué (Cache Adapter)

4. Intégration de Services d’Authentification (Security Adapter)

⚠️ Erreurs courantes à éviter

1. Pollution du Domain Model par les types externes

2. Dépendance directe de l’Use Case à l’Adapter

3. Négliger les Mocks pour les tests unitaires

4. Gestion complexe des transactions distribuées

✔️ Bonnes pratiques

1. Séparation stricte des Packages et des Dépendances

2. Définir les Ports au niveau du Domaine

3. Propager le Contexte Go

4. Valider les données dès le Domain Model

5. Regrouper les Adapters par Fonctionnalité

✅ Conclusion

Profilage continu Go Pyroscope : Optimisez vos services Go

limitation de débit Go : Maîtriser le rate limiting avancé

Gestion des pointeurs Go : Valeur vs Référence en profondeur

Middleware HTTP en Go : le pattern de composition

Arrêt propre serveur Go : Maîtriser le shut down des API

générateur QR code Go : Guide avancé de la génération

Un commentaire

Laisser un commentaire Annuler la réponse

Architecture hexagonale Go : Ports et Adapters maîtrisés

🛠️ Prérequis

Connaissances requises

Installation et configuration

📚 Comprendre architecture hexagonale Go

Ports et Adapters : Le cœur théorique

Schéma de dépendance

🐹 Le code — architecture hexagonale Go

📖 Explication détaillée

Le rôle de l’interface comme Port (Ports/Adapter Ports)

Le cas d’usage : le cœur métier (Use Case)

L’Adapter (PostgresAdapter)

🔄 Second exemple — architecture hexagonale Go

▶️ Exemple d’utilisation

🚀 Cas d’usage avancés

1. Intégration avec une API REST Tiers (Adapter Externe)

2. Gestion Asynchrone par Message Queue (Message Adapter)

3. Persistance en Cache Distribué (Cache Adapter)

4. Intégration de Services d’Authentification (Security Adapter)

⚠️ Erreurs courantes à éviter

1. Pollution du Domain Model par les types externes

2. Dépendance directe de l’Use Case à l’Adapter

3. Négliger les Mocks pour les tests unitaires

4. Gestion complexe des transactions distribuées

✔️ Bonnes pratiques

1. Séparation stricte des Packages et des Dépendances

2. Définir les Ports au niveau du Domaine

3. Propager le Contexte Go

4. Valider les données dès le Domain Model

5. Regrouper les Adapters par Fonctionnalité

✅ Conclusion

Publications similaires

Un commentaire

Laisser un commentaire Annuler la réponse