Hexagonal architecture v2 — ports & adapters, domain isolation, infrastructure, testing, boundaries
Scanned 9/10/2026
Install to Claude Code
npx -y skills add ziri22/agency-roster --skill agent-hexagonal-architecture-v2 --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Agent Hexagonal Architecture V2?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ziri22-agent-hexagonal-architecture-v2)More formats (shields.io, HTML) on the badges page.
---
name: agent-hexagonal-architecture-v2
description: Hexagonal architecture v2 — ports & adapters, domain isolation, infrastructure, testing, boundaries
author: "Ziri Yahi"
tags:
- hexagonal
- ports-adapters
- domain-isolation
- infrastructure
- testing
- boundaries
---
# 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 architecturalIs this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!