Roadmap des talents
Craft
Profil Software Craftsman — conception métier rigoureuse.
Persona Software Craftsman — conception métier rigoureuse : architecture, DDD, tests,
refactoring. La liste ci-dessous est exhaustive : les 17 talents déjà publiés (✅) et la
profondeur restante (P0 → P2).
Décisions de taxonomie issues de la revue des talents — elles guident la liste ci-dessous :
- Familles d'architecture séparées.
architecture.hexagonal se recentre sur ses quatre
concepts (port/adapter, domaine, infra) ; la notion de use-case relève de
architecture.clean, pas de l'hexagonal. Hexagonal, Clean et Onion se recommandent
mutuellement plutôt que de se lier en dur : on ne « nomme » pas l'archi, on prend les concepts
voulus (un talent peut citer le concept de plus haut niveau d'où il vient — axe formation).
architecture.three-tier couvre les petits domaines.
- Le TDD n'est pas un talent de test (c'est une méthode de dev) → famille
quality. Pour une
IA, privilégier quality.test-first (le test précède le code, sans micro-cycle) ;
quality.tdd reste pour qui veut garder la main (validation pas à pas).
api.idempotency = idempotence HTTP uniquement (clés d'idempotence). Le cas « n'émettre
l'événement qu'après le commit » est le outbox pattern (integration.outbox) — à ne pas
confondre.- Patterns d'intégration/résilience (circuit-breaker, retry, compensation, saga) = talents
d'architecture (avant le code), regroupés sous la famille
integration.
- Concepts transverses à porter par le moteur (hors talents) : sélection partielle d'un
composite (prendre
use-case sans output-port), niveaux de talent (CQRS simple → DB séparée
→ +event-driven), talents par personne (outside-in vs inside-out, via install/désactivation
MCP), et l'aperçu d'un talent comme support de formation.
Points relevés sur le catalogue actuel, à retravailler — la génération initiale par l'IA a mélangé
certains concepts :
| Talent | Correctif |
|---|
architecture.hexagonal | Retirer requires: architecture.use-case (le use-case relève de Clean). Recentrer le contenu (compact.md / talent.md) sur port/adapter + domaine + infra ; les étapes « use case » sortent du talent. |
architecture.use-case | Rattacher conceptuellement à Clean : devenir un requires de architecture.clean plutôt qu'un satellite d'hexagonal. |
ddd.tactical | Vérifier le mélange de concepts « clean » signalé pendant la revue ; retravailler le corps si besoin. |
api.idempotency (backlog) | Requalifier en idempotence HTTP ; sortir le « event après commit » vers integration.outbox. |
testing.property-based (backlog) | Mal rattaché par l'IA à API / event-driven ; contexte = testing (déjà reclassé ici). |
flowchart TB
classDef existing fill:#eee,stroke:#999,color:#555;
classDef composite fill:#e7e3ff,stroke:#6d5ef6,color:#3a2f9e;
classDef atomic fill:#fff,stroke:#6d5ef6,color:#3a2f9e;
hexa["hexagonal"]:::existing
usecase["architecture.use-case"]:::existing
bdd["testing.bdd"]:::existing
ulang["ubiquitous-language"]:::existing
domevt["domain-event"]:::existing
deprule["dependency-rule"]:::existing
clean["architecture.clean"]:::composite
onion["architecture.onion"]:::composite
bc["ddd.bounded-context"]:::composite
cmap["ddd.context-map"]:::atomic
acl["ddd.anti-corruption-layer"]:::atomic
tdd["quality.tdd"]:::composite
tfirst["quality.test-first"]:::atomic
di["design.dependency-inversion"]:::atomic
solid["design.solid"]:::composite
cqrs["architecture.cqrs"]:::composite
eda["architecture.event-driven"]:::composite
outbox["integration.outbox"]:::atomic
clean --> usecase
hexa -.-> clean
clean -.-> hexa
clean -.-> onion
hexa -.-> onion
ulang --> bc
bc --> cmap
bc --> acl
bdd --> tdd
bdd -.-> tfirst
deprule --> di
di --> solid
hexa -.-> cqrs
domevt --> eda
cqrs -.-> eda
domevt --> outbox
outbox -.-> eda
✅ = déjà publié au catalogue · P0 → P2 = à développer. Dans « Dépend de » : → requires · ≈ recommends · ⊃ inclut (composite).
| Talent | Type | P | Dépend de | Description |
|---|
architecture.hexagonal | composite | ✅ | → dependency-rule, use-case ⚠️, port-adapter, value-object · ≈ ddd.tactical, domain-event | Backend où le domaine reste indépendant de l'infra. (⚠️ voir correctifs) |
architecture.use-case | atomic | ✅ | → dependency-rule · ≈ port-adapter, acceptance-tests | Action applicative qui orchestre le domaine via des ports. |
architecture.dependency-rule | atomic | ✅ | ≈ port-adapter | Les dépendances pointent vers le domaine ; jamais l'inverse. |
architecture.port-adapter | atomic | ✅ | → dependency-rule | Ports côté domaine/application, adaptateurs côté infra. |
architecture.clean | composite | P0 | → use-case · ≈ hexagonal | Use-cases, frontières, règle de dépendance ; présenteur / output-port en option. |
architecture.onion | composite | P1 | ≈ hexagonal · ≈ clean | Domaine scindé en domain-service / application-service. |
architecture.three-tier | composite | P2 | — | Présentation / business service / accès données — petits domaines. |
architecture.vertical-slicing | atomic | P1 | ≈ hexagonal | Découper par tranche fonctionnelle plutôt que par couche (respecter l'ordre des dépendances). |
architecture.modular-monolith | composite | P2 | → bounded-context | Monolithe modulaire : modules à frontières nettes avant tout split en services. |
architecture.cqrs | composite | P1 | ≈ hexagonal · ≈ aggregate | Séparer modèles de lecture et d'écriture (niveaux : même DB → DB séparée → +event-driven). |
architecture.event-driven | composite | P1 | → domain-event · ≈ cqrs | Découplage asynchrone, cohérence à terme. |
| Talent | Type | P | Dépend de | Description |
|---|
ddd.tactical | composite | ✅ | ⊃ entity, value-object, aggregate, domain-event, repository, domain-service · ≈ hexagonal, ubiquitous-language | Modéliser le cœur métier avec des objets expressifs protégés par des invariants. |
ddd.value-object | atomic | ✅ | → ubiquitous-language · ≈ primitive-obsession | Valeur métier validée et immuable. |
ddd.entity | atomic | ✅ | ≈ ubiquitous-language, value-object | Objet métier avec une identité stable dans le temps. |
ddd.aggregate | atomic | ✅ | → entity · ≈ domain-event, repository | Frontière de cohérence transactionnelle autour d'une racine. |
ddd.domain-event | atomic | ✅ | ≈ aggregate, ubiquitous-language | Fait métier survenu, capturé comme événement immuable. |
ddd.repository | atomic | ✅ | → aggregate · ≈ port-adapter | Abstraire la persistance d'un aggregate derrière un port. |
ddd.domain-service | atomic | ✅ | ≈ ubiquitous-language | Logique métier sans entité naturelle propre. |
ddd.ubiquitous-language | atomic | ✅ | — | Aligner le code sur le vocabulaire métier partagé. |
ddd.bounded-context | composite | P0 | ≈ ubiquitous-language | Délimiter un contexte métier cohérent — concrètement un package/module à forte cohésion, faible couplage. |
ddd.context-map | atomic | P1 | → bounded-context | Relations entre contextes (ACL, conformist, customer/supplier…). |
ddd.anti-corruption-layer | atomic | P1 | → bounded-context · ≈ context-map | Traduire à la frontière d'un contexte externe (≈ rôle des ports/adapters). |
ddd.specification | atomic | P1 | ≈ value-object | Encapsuler une règle métier composable. |
ddd.factory | atomic | P2 | ≈ aggregate · ≈ value-object | Encapsuler la création d'objets riches quand elle porte de la logique. |
ddd.shared-kernel | atomic | P2 | → bounded-context | Noyau partagé entre contextes (lib commune) — couplage assumé. |
ddd.open-host-service | atomic | P2 | ≈ context-map · ≈ api.contract-first | Service ouvert + published language (OpenAPI / protobuf). |
| Talent | Type | P | Dépend de | Description |
|---|
testing.bdd | atomic | ✅ | → acceptance-criteria · ≈ acceptance-tests, ubiquitous-language | Spécifier le comportement par l'exemple (Given/When/Then). |
testing.acceptance-tests | atomic | ✅ | → acceptance-criteria · ≈ bdd, use-case | Tests d'acceptation pilotés par les critères. |
testing.contract-tests | atomic | ✅ | → port-adapter · ≈ acceptance-tests | Vérifier le contrat entre consommateur et fournisseur. |
testing.test-doubles | atomic | P1 | ≈ tdd · ≈ port-adapter | Mocks / stubs / fakes / spies : quand et lequel. |
testing.test-pyramid | atomic | P1 | ≈ bdd | Répartition unit / intégration / E2E. |
testing.approval-testing | atomic | P1 | ≈ refactoring.patterns · ≈ contract-tests | Figer une sortie de référence (golden master) — refacto/legacy & Storybook. |
testing.mutation-testing | atomic | P1 | ≈ test-pyramid | Mesurer la qualité des tests par mutants. |
testing.outside-in | atomic | P2 | ≈ tdd | Développer de l'API vers l'intérieur (double boucle) — alternative à inside-out. |
testing.property-based | atomic | P2 | ≈ test-doubles | Tester des invariants sur entrées générées. |
testing.test-data-builders | atomic | P2 | ≈ test-doubles | Builders / object mother pour des données de test lisibles. |
| Talent | Type | P | Dépend de | Description |
|---|
quality.test-first | atomic | P0 | ≈ bdd | Écrire le test avant le code — variante adaptée à l'IA (pas de micro-cycle). |
quality.tdd | composite | P1 | → bdd · ≈ acceptance-tests | Cycle red-green-refactor — pilotage pas à pas, humain dans la boucle. |
quality.continuous-verification | atomic | P2 | ≈ tdd | « never commit on red ». |
quality.tcr | atomic | P2 | ≈ continuous-verification | Test && Commit || Revert — incréments atomiques. |
quality.code-review | atomic | P2 | — | Revue orientée comportement et conception. |
quality.technical-debt | atomic | P2 | ≈ refactoring.patterns | Identifier, classer et rembourser la dette. |
| Talent | Type | P | Dépend de | Description |
|---|
design.dependency-inversion | atomic | P0 | ≈ dependency-rule · ≈ port-adapter | Dépendre d'abstractions (le « D » de SOLID). |
clean-code.naming | atomic | P0 | ≈ ubiquitous-language | Nommer par l'intention et le vocabulaire métier. |
clean-code.small-functions | atomic | P1 | ≈ naming | Fonctions courtes, une responsabilité, niveaux d'abstraction homogènes. |
design.solid | composite | P1 | → dependency-inversion | Les cinq principes SOLID. |
design.coupling-cohesion | atomic | P1 | ≈ dependency-inversion | Couplage faible, forte cohésion — la boussole de conception. |
design.tell-dont-ask | atomic | P2 | ≈ entity | Confier le comportement à l'objet qui détient l'état. |
error-handling.domain-errors | atomic | P0 | ≈ hexagonal · ≈ value-object | Modéliser les échecs dans le langage du domaine. |
error-handling.result-type | atomic | P1 | ≈ domain-errors | Result / Either typé plutôt qu'exceptions pour les échecs attendus. |
| Talent | Type | P | Dépend de | Description |
|---|
refactoring.primitive-obsession | atomic | ✅ | → value-object · ≈ ubiquitous-language | Remplacer les types primitifs par des value objects. |
refactoring.guard-clause | atomic | P0 | ≈ primitive-obsession | Aplatir les conditionnels par sorties anticipées. |
refactoring.patterns | composite | P2 | ≈ guard-clause | Catalogue Fowler : strangler fig, parallel change… |
refactoring.replace-conditional | atomic | P2 | ≈ guard-clause | Remplacer un switch par du polymorphisme (à pondérer : pas toujours plus simple). |
| Talent | Type | P | Dépend de | Description |
|---|
integration.outbox | atomic | P1 | → domain-event · ≈ event-driven | N'émettre l'événement qu'après le commit transactionnel. |
integration.circuit-breaker | atomic | P1 | — | Couper les appels vers une dépendance défaillante (arrêter de « tabasser » l'API). |
integration.retry | atomic | P1 | ≈ circuit-breaker | Réessais avec backoff, jitter, budget. |
integration.dead-letter | atomic | P2 | ≈ retry | File de rejets (DLQ), reprise, poison messages. |
integration.compensation | atomic | P2 | ≈ saga | Action de compensation quand un partenaire échoue (état partiel comblé plus tard). |
integration.saga | composite | P2 | → domain-event · ≈ compensation | Transaction distribuée : orchestration vs chorégraphie. |
| Talent | Type | P | Dépend de | Description |
|---|
api.contract-first | atomic | P1 | ≈ contract-tests | OpenAPI, versioning, breaking changes. |
api.error-format | atomic | P2 | ≈ contract-first | Format d'erreur standard (RFC 7807 problem+json). |
api.idempotency | atomic | P2 | ≈ api.contract-first | Idempotence des opérations HTTP (clés d'idempotence) — distinct de l'outbox. |
| Talent | Type | P | Dépend de | Description |
|---|
observability.structured-logging | atomic | P1 | — | Logs structurés, correlation id, redaction PII. (volet métriques/traces : profil DevOps) |
Cible : un persona Architecte (livrables = schémas, avant ou en marge du dev) — voir Personas.
| Talent | Type | P | Dépend de | Description |
|---|
documentation.sequence-diagram | atomic | P2 | — | Diagramme de séquence par geste (API → base → partenaires) en livrable. |
documentation.architecture-diagram | atomic | P2 | ≈ context-map | C4 / Mermaid / PlantUML — schémas d'archi-solution. |
| Talent | Type | P | Dépend de | Description |
|---|
product.acceptance-criteria | atomic | ✅ | — | Formuler des critères d'acceptation vérifiables. |
product.user-story | atomic | P1 | ≈ acceptance-criteria | Formuler une story orientée valeur. |
product.story-splitting | atomic | P2 | → user-story | Découper une story en incréments livrables. |
product.example-mapping | atomic | P2 | ≈ bdd · ≈ acceptance-criteria | Cartographier règles et exemples (atelier Three Amigos). |