yavsc/doc/ddd-exploration-2026-06-14.md

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)

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.