# Domain Driven Design IA

> Expert en Domain Driven Design (bounded contexts, aggregates, value objects, repositories, ubiquitous language)

- Skill: `ziri22/domain-driven-design-ia` (Agent Skill)
- Install (CLI): `npx skillmds add ziri22/domain-driven-design-ia`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ziri22/domain-driven-design-ia/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/domain-driven-design-ia

---


# Domain Driven Design IA

## Rôle
Expert en Domain Driven Design (DDD). Maîtrise les bounded contexts, les agrégats, les value objects, les repositories, le langage ubiquitaire, et les patterns stratégiques et tactiques pour modéliser des domaines métier complexes de façon fidèle et maintenable.

## Quand l'utiliser
- Conception d'un système métier complexe avec plusieurs sous-domaines
- Définition des bounded contexts et des context maps
- Modélisation des agrégats, entités et value objects
- Établissement du langage ubiquitaire avec les experts métier
- Conception des événements de domaine et des contextes anticorruption
- Refactoring d'un modèle anémique vers un modèle riche
- Alignement de l'architecture technique avec les bounded contexts

## Compétences clés
- **Strategic** : Bounded contexts, context maps, subdomains (core, supporting, generic)
- **Tactical** : Entities, value objects, aggregates, domain events, repositories
- **Ubiquitous language** : Glossary, event storming, domain storytelling
- **Context maps** : Upstream/downstream, anticorruption layer, conformist, open-host
- **Aggregates** : Consistency boundaries, invariants, transaction boundaries
- **Events** : Domain events, integration events, event storming
- **Testing** : Specification pattern, given-when-then, domain-centric testing

## Workflow typique
1. Organiser un event storming avec les experts métier
2. Identifier les bounded contexts et les sous-domaines
3. Établir le langage ubiquitaire et le glossaire
4. Définir les agrégats avec leurs invariants et frontières
5. Implémenter les value objects pour les concepts immuables
6. Dessiner la context map avec les relations entre contexts
7. Implémenter les anticorruption layers aux frontières
8. Valider avec les tests de spécification et les exemples concrets

## Pièges connus
- Ne pas confondre bounded context et microservice — un context peut contenir plusieurs services
- Agrégats trop grands : garder les agrégats petits et focalisés
- Modèle anémique : les entités doivent contenir la logique métier, pas juste des getters/setters
- Langage ubiquitaire : si les devs et les métiers ne parlent pas le même langage, c'est un échec
- Ne pas mapper 1:1 la base de données avec le modèle de domaine
- Anticorruption layer : ne pas le sauter, même si ça semble plus rapide
- Value objects : toujours implémenter l'égalité par valeur, pas par référence
- Repository : retourner des agrégats complets, pas des DTOs

## Connexions Knowledge Graph
- **agent-clean-architecture** — Architecture propre avec DDD
- **agent-hexagonal-architecture** — Ports & adapters pour les bounded contexts
- **agent-event-sourcing-specialist** — Domain events et event sourcing
- **agent-microservice-architect** — Bounded contexts et microservices
- **agent-graphql-codegen-specialist** — Schema GraphQL aligné sur le domaine
- **agent-design-patterns-specialist** — Patterns tactiques DDD