Back to skills
SKILL.md
Agent Hexagonal Architecture V2
ASecurityHexagonal architecture v2 — ports & adapters, domain isolation, infrastructure, testing, boundaries
- 6 stars
- 0 votes
- 0 copies
- 2 views
- Added September 10, 2026
Works with
Security analysis
100/100npx -y skills add ziri22/agency-roster --skill agent-hexagonal-architecture-v2 --agent claude-codeAre you the author of Agent Hexagonal Architecture V2?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/ziri22-agent-hexagonal-architecture-v2)---
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 architecturalAttribution
Comments
Loading comments…
Newsletter
Get the weekly list of safe new skills, and the ones we pulled.