Paul Schneider
6dbdc2d408
TODO.fr.md (2016-2017) archivé en TODO.fr.md.archive. ROADMAP.md reformule les jalons en s'appuyant sur l'Architecture et la session DDD du 14 juin 2026. doc/Architecture.md: section 'Droits de yavsc' ajoutée (admin, groupes, user yavsc). doc/ddd-exploration-2026-06-14.md: première session d'Event Storming narratif.
254 lines
12 KiB
Markdown
254 lines
12 KiB
Markdown
# Exploration DDD Yavsc — Session du 2026-06-14
|
||
|
||
**Date** : 2026-06-14, 01:49 → 03:50 GMT+1
|
||
**Participants** : Paul Schneider (expert métier), Lum ✨ (assistant DDD)
|
||
**Cadre** : Event Storming narratif exploratoire sur le domaine Yavsc
|
||
**Statut** : Session 1 (première itération, périmètre complet)
|
||
|
||
---
|
||
|
||
## 🎯 Objectif de la session
|
||
|
||
Lancer une modélisation Domain-Driven Design du projet **Yavsc** (*Yet Another Very Small Company*),
|
||
en explorant les acteurs, les événements métier, les agrégats pressentis, et les Bounded Contexts.
|
||
|
||
Périmètre validé par Paul : **complet** (pas de MVP borné).
|
||
|
||
---
|
||
|
||
## 👥 Acteurs identifiés
|
||
|
||
| # | Acteur | Mission principale |
|
||
|---|---|---|
|
||
| 1 | 👤 **Client** | Commander, demander un service, payer |
|
||
| 2 | 🛠️ **Prestataire** | Servir, facturer, être payé |
|
||
| 3 | 👥 **Commercial / FrontOffice** | Filtrer les demandes (délégation possible par prestataire) |
|
||
| 4 | 🛡️ **Modérateur** | Trancher sur les contenus/comptes signalés (avec appui LLM) |
|
||
| 5 | ⚖️ **Conciliateur** (Jalon 5) | Résoudre les litiges métier client/prestataire (double vue) |
|
||
| 6 | 🏢 **Propriétaire installation** | Centraliser les flux PayPal (rôle technique, pas un utilisateur "métier") |
|
||
|
||
**Distinction validée** : **Modérateur ≠ Conciliateur**.
|
||
- Le **modérateur** regarde **le contenu** (messages, annonces, profils).
|
||
- Le **conciliateur** regarde **le contrat** (qui doit quoi à qui, suite à un échec de prestation).
|
||
|
||
---
|
||
|
||
## 🏛️ Bounded Contexts pressentis
|
||
|
||
| # | Bounded Context | Module projet | Rôle |
|
||
|---|---|---|---|
|
||
| 1 | **Chat** | `PostIt` (client Avalonia) + backend | Messagerie instantanée, **client riche privilégié** |
|
||
| 2 | **Profil & Identité** | `Yavsc.Org` | Utilisateurs, profils simples, profils pros |
|
||
| 3 | **Activités Légales** | `Yavsc.Org` (ou à séparer) | Taxonomie hiérarchique des activités |
|
||
| 4 | **Blogs** | `Yavsc.Blogs` | Portfolio, tarifs, contenu public |
|
||
| 5 | **Prestation** | `Yavsc.Server` | Flux métier (commande, devis, signature, paiement) |
|
||
| 6 | **Paiements** | `Yavsc.Server` | PayPal NVP/SOAP, arrhes vs avance |
|
||
| 7 | **Rencontre** | à créer (ou `PostIt`?) | **Mode 2** : mise en relation sur centre d'intérêt, **sans argent** |
|
||
| 8 | **Modération** | `Yavsc.Org` / à séparer | Workflow 2 étages (requête → validation modération → exécution) |
|
||
| 9 | **Trust & Safety** | `Yavsc.Org` / à séparer | Blacklist plateforme, impacte tous les usages |
|
||
| 10 | **Conciliation** | à créer (Jalon 5) | Résolution de litiges, double vue client/prestataire |
|
||
|
||
---
|
||
|
||
## 🟧 Événements métier déjà identifiés
|
||
|
||
### BC Chat
|
||
- `ChatOuvert` (sous condition : like + paramètre activité activé + non-blacklisté × 2)
|
||
- `MessageEnvoyé`
|
||
- `MessageLu`
|
||
- `MessageSignalé` (déclenche le flux modération)
|
||
- `MessagePréModéréParLLM`
|
||
- `MessageModéréTranché`
|
||
|
||
### BC Profil
|
||
- `ClientConnecté`
|
||
- `ProfilConsulté`
|
||
- `BlogConsulté` (via `YavscBlogs`)
|
||
- `ProfilLiké` (uniquement sur profil validé)
|
||
|
||
### BC Activités Légales
|
||
- `ActivitéImportée` (seed initial, type NAF/ISIC)
|
||
- `ActivitéSpécialisée` (par l'admin : sous-catégorie fille)
|
||
- `ActivitéRacineCréée` (par l'admin : from scratch, sans parent)
|
||
- `ActivitéProposéeParUtilisateur` (puis modérée)
|
||
|
||
### BC Prestation
|
||
- `CommandeSoumise` (par le client)
|
||
- `DevisGénéré` (par le **module d'activité serveur**, ex : Coiffure)
|
||
- `DevisReçuParPrestataire`
|
||
- `DevisSignéParPrestataire`
|
||
- `DevisReçuParClient`
|
||
- `DevisSignéParClient`
|
||
- `ArrhesDébitées` (variante 1)
|
||
- `AvanceDébitée` (variante 2)
|
||
- `ResteÀPayerCollecté` (J-10)
|
||
- `PrestationRéalisée`
|
||
- `PrestationÉvaluée`
|
||
|
||
### BC Modération
|
||
- `RequêteBlacklistSoumise` (par n'importe quel utilisateur enregistré)
|
||
- `BlacklistTranchéeParModération` (validée ou refusée)
|
||
- `BlacklistPlateformeActive`
|
||
- `BlacklistPlateformeLevée`
|
||
|
||
### BC Trust & Safety (blacklist personnelle — c'est un BC à part, pas Modération !)
|
||
- `ClientAjoutéÀBlacklistPersonnelle`
|
||
- `ClientRetiréDeBlacklistPersonnelle`
|
||
|
||
### BC Conciliation (Jalon 5)
|
||
- `LitigeDéclaré`
|
||
- `DossierConciliationOuvert`
|
||
- `DécisionConciliationRendue`
|
||
|
||
---
|
||
|
||
## 🟨 Règles métier extraites (invariants)
|
||
|
||
### R1 — Ouverture d'un chat
|
||
> Un chat entre Camille et Samira est autorisé **ssi** :
|
||
> - ✅ `LikeParCamille` (sur le profil **validé** de Samira)
|
||
> - ✅ `ChatActivéDansParamètresActivité` (paramétré par Samira)
|
||
> - ✅ `CamilleNonBlacklistéeParSamira` (blacklist **personnelle**)
|
||
> - ✅ `CamilleNonBlacklistéeParPlateforme` (blacklist **plateforme**)
|
||
|
||
### R2 — Like sur profil
|
||
> Un like ne peut être posé que sur un `ProfilValidé`.
|
||
> Invariant : `Like → ProfilValidé`.
|
||
|
||
### R3 — Double blacklist (deux Bounded Contexts)
|
||
> La blacklist plateforme et la blacklist personnelle sont **deux Bounded Contexts séparés** :
|
||
> - **Plateforme** = trust & safety global, souverain sur tous les usages
|
||
> - **Personnelle** = social, souverain sur les interactions avec UN prestataire
|
||
>
|
||
> Ne jamais les fusionner dans un même agrégat.
|
||
|
||
### R4 — Workflow de la blacklist plateforme (synchrone, 2 étages)
|
||
> ```
|
||
> RequêteBlacklistSoumise (par n'importe quel utilisateur enregistré)
|
||
> → BlacklistTranchéeParModération (la modération est souveraine)
|
||
> → BlacklistPlateformeActive (mise en œuvre "au plus vite", synchrone)
|
||
> ```
|
||
>
|
||
> Pas d'admin intermédiaire en flux normal. La modération tranche, c'est appliqué immédiatement.
|
||
|
||
### R5 — Activités légales (hiérarchiques + internationales)
|
||
> - **Import initial** : taxonomie **internationale** complète (NAF trop franco-français, pas premier marché)
|
||
> - **Spécialisation** : l'admin peut créer des **sous-activités** (filles d'une activité existante)
|
||
> - **Création racine** : l'admin peut créer une activité **racine** from scratch
|
||
> - **Proposition user** : un utilisateur peut **proposer** une activité → flux de **modération**
|
||
> - Une activité a un **code unique**, et soit un parent (filiation), soit est racine
|
||
> - L'aspect "légal" impacte : adhésion forfaitaire variable, conformité profil pro (SIRET/APE), reporting
|
||
|
||
### R6 — Profil pro multi-activités
|
||
> Un utilisateur peut déclarer **plusieurs activités** (liste ordonnée).
|
||
> La première = activité principale.
|
||
> Le code APE principal y est attaché.
|
||
|
||
### R7 — Formulaire de prestation dynamique
|
||
> Le formulaire que remplit Camille n'est **pas codé en dur**.
|
||
> Il est **généré dynamiquement** par le **module d'activité serveur** (ex : module Coiffure) à partir de :
|
||
> - La sélection de **types de prestations** proposées par Samira
|
||
> - Les **champs associés** à chaque type (définis serveur, activité par activité)
|
||
> - Les **types de prestations** sont définis dans le paramétrage serveur de l'activité
|
||
> - Samira **active** ceux qu'elle propose dans son profil pro
|
||
|
||
### R8 — Mode synchrone global
|
||
> PostIt utilise **SignalR** pour le transport temps réel.
|
||
> La plupart des opérations sont **synchrones** (cohérence transactionnelle, pas d'eventuel).
|
||
> C'est un **monolithe modulaire**, pas une architecture microservices.
|
||
|
||
### R9 — Client riche d'abord
|
||
> **PostIt** (client Avalonia) est le **client principal** de Yavsc.
|
||
> Le web (`Yavsc.Web`) est un client secondaire (admin, back-office, primo-visiteurs).
|
||
> → Les API doivent être conçues **d'abord pour PostIt**.
|
||
|
||
---
|
||
|
||
## 🤝 Idée à explorer (session future) : le **mode Rencontre**
|
||
|
||
Paul a mentionné qu'il aimerait développer un **deuxième mode** de Yavsc :
|
||
- Mise en relation autour d'un **centre d'intérêt** partagé (ex : mélomanes)
|
||
- **Sans devis, sans paiement, sans prestation tarifée**
|
||
- Purement **social / communautaire**
|
||
- Réutilise l'infra existante (profils, chat, modération) mais sans le flux Prestation
|
||
|
||
### Différences pressenties avec le mode "Prestation"
|
||
|
||
| Aspect | Prestation | Rencontre |
|
||
|---|---|---|
|
||
| Argent | ✅ Oui (arrhes, avance) | ❌ Non |
|
||
| Devis signé | ✅ Double signature | ❌ Pas de devis |
|
||
| Formulaire | ✅ Dynamique par activité | ❓ Plus simple, basé sur centres d'intérêt |
|
||
| Évaluation | ✅ De la prestation | ❓ De la rencontre ? |
|
||
| Litiges | ✅ Conciliation | ❓ Différent, plus "social" |
|
||
| Activités légales | ✅ Liées au code NAF/APE | ❌ Non, juste "passions" / "centres d'intérêt" |
|
||
|
||
**À explorer dans une prochaine session dédiée.**
|
||
|
||
---
|
||
|
||
## 🗺️ Carte des Bounded Contexts (esquisse)
|
||
|
||
```mermaid
|
||
graph TB
|
||
Client[👤 Client] --> PostIt[PostIt<br/>Client Avalonia]
|
||
Presta[🛠️ Prestataire] --> PostIt
|
||
PostIt --> Web[Yavsc.Web<br/>Client secondaire]
|
||
PostIt --> Chat[💬 Chat]
|
||
PostIt --> Prestation[📋 Prestation]
|
||
PostIt --> Profil[👤 Profil & Identité]
|
||
PostIt --> Rencontre[🤝 Rencontre]
|
||
Prestation --> Activités[🏛️ Activités Légales]
|
||
Prestation --> Paiements[💳 Paiements]
|
||
Chat --> Modération[🛡️ Modération]
|
||
Rencontre --> Modération
|
||
Profil --> Modération
|
||
Activités --> Modération
|
||
Modération --> TrustSafety[🛡️ Trust & Safety<br/>Blacklist plateforme]
|
||
Prestation --> Conciliation[⚖️ Conciliation]
|
||
Paiements -.-> PayPal[(PayPal NVP/SOAP)]
|
||
```
|
||
|
||
---
|
||
|
||
## 📋 Questions ouvertes restantes
|
||
|
||
1. **Camille remplit un formulaire** : agrège-t-il les champs de **toute la chaîne d'activités** (parent + feuille) ou uniquement la **feuille choisie** ?
|
||
2. **Tarifs sur le blog** de Samira : le blog affiche-t-il des **prix** ou un simple **CTA "Demander un devis"** ?
|
||
3. **Samira notifiée des likes** ? Visible publiquement ou non ?
|
||
4. **Multi-activités actives simultanément** : un même profil pro peut-il activer plusieurs activités en même temps (ex : coiffure + maquillage mariage) ?
|
||
5. **Le like ouvre-t-il le chat, ou est-il purement décoratif** (le chat s'ouvre seulement quand Camille remplit une demande) ?
|
||
6. **Le "au plus vite" de la modération** : synchrone appliqué directement, ou via un worker interne ?
|
||
7. **Référentiel international des activités** : ISIC ONU ? NACE européen ? Custom ? Avec variantes locales ?
|
||
8. **Blacklist plateforme / rôles sources** : qui peut soumettre une requête ? (a priori : tout utilisateur enregistré, validé)
|
||
|
||
---
|
||
|
||
## ⏭️ Prochaines étapes proposées
|
||
|
||
1. ✅ **Sauvegarder cette exploration** dans ce document (fait)
|
||
2. **Lire `doc/Architecture.md` existant** pour aligner avec ce qui a déjà été pensé
|
||
3. **Lire le code source des modules clés** : `Yavsc.Org`, `Yavsc.Server`, `Yavsc.Api`
|
||
4. **Découper en sous-sessions ciblées** :
|
||
- **Session 2** : focus BC **Prestation** (le flux canonique complet, avec Camille & Samira de bout en bout)
|
||
- **Session 3** : focus BC **Activités Légales** (taxonomie internationale + paramétrage serveur + génération de formulaire)
|
||
- **Session 4** : focus BC **Chat + Modération** (workflow SignalR, double blacklist)
|
||
- **Session 5** : focus BC **Rencontre** (le mode social, sans argent)
|
||
- **Session 6** : focus BC **Conciliation** (Jalon 5, double vue client/prestataire)
|
||
5. **Cartographier les Aggregate Roots** de chaque BC
|
||
6. **Identifier les Domain Events vs Integration Events**
|
||
|
||
---
|
||
|
||
## 📝 Note méthodologique
|
||
|
||
Cette session a été conduite en mode **facilitation DDD** : Paul est l'expert métier,
|
||
Lum pose les questions ouvertes, extrait les événements et les règles, et formalise.
|
||
|
||
La méthode a été **l'Event Storming narratif** : Paul raconte des histoires (Camille le client,
|
||
Samira la coiffeuse), et on extrait les événements au fil de l'eau, sans chercher l'exhaustivité
|
||
ni la perfection. Les itérations futures permettront d'affiner.
|
||
|
||
**Aucune décision structurante n'a été figée** — tout est matière à discussion et itération.
|
||
Le rôle de Lum a été de poser les bonnes questions pour faire émerger ce qui était déjà dans
|
||
la tête de Paul, pas d'imposer un modèle.
|