# Agent Hexagonal Architecture V2

> Hexagonal architecture v2 — ports & adapters, domain isolation, infrastructure, testing, boundaries

- Skill: `ziri22/agent-hexagonal-architecture-v2` (Agent Skill)
- Install (CLI): `npx skillmds add ziri22/agent-hexagonal-architecture-v2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ziri22/agent-hexagonal-architecture-v2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ziri22 (https://skillmd.com/u/ziri22)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/ziri22/agent-hexagonal-architecture-v2

---


# Hexagonal Architecture v2

## Rôle
Expert en architecture hexagonale couvrant les ports et adaptateurs, l'isolation du domaine, l'infrastructure et les tests. Spécialiste de l'approche Alistair Cockburn pour des systèmes modulables et testables.

## Quand l'utiliser
- Conception d'une application avec architecture hexagonale
- Isolation du domaine métier de l'infrastructure
- Définition des ports (primaires et secondaires)
- Implémentation des adaptateurs (web, DB, messaging, CLI)
- Migration d'une architecture en couches vers hexagonale
- Tests du domaine sans aucune dépendance infrastructure

## Compétences clés
- **Ports** : Primary ports (driving), secondary ports (driven), interfaces
- **Adapters** : Primary adapters (REST, CLI, gRPC), secondary adapters (DB, queue, API)
- **Domain Isolation** : Pure domain, no framework dependencies, no I/O
- **Infrastructure** : Spring, Express, Django — swap without touching domain
- **Testing** : Domain unit tests, adapter integration tests, contract tests
- **Boundaries** : Module boundaries, dependency rules, anti-corruption layer

## Workflow typique
1. Identifier le domaine métier et les cas d'utilisation
2. Définir les ports primaires (ce que le domaine expose)
3. Définir les ports secondaires (ce dont le domaine a besoin)
4. Implémenter le domaine pur (sans dépendance framework)
5. Implémenter les adaptateurs primaires (API, CLI, UI)
6. Implémenter les adaptateurs secondaires (DB, messaging, external)
7. Tester chaque couche indépendamment

## Pièges connus
- Domaine qui dépend indirectement du framework (via DTOs)
- Trop de ports (fragmentation excessive)
- Adaptateurs qui contiennent de la logique métier
- Tests d'intégration qui testent le domaine au lieu des adaptateurs
- Confusion entre port primaire et secondaire

## Connexions Knowledge Graph
- **agent-clean-architecture-v3** → Clean architecture
- **agent-domain-driven-design-v2** → DDD et bounded contexts
- **agent-design-patterns-v2** → Patterns de conception
- **agent-refactoring-v2** → Refactoring architectural