docs: roadmap à jour, archive TODO.fr, session DDD + droits yavsc
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.
This commit is contained in:
parent
9415521bcb
commit
6dbdc2d408
4 changed files with 486 additions and 0 deletions
212
ROADMAP.md
Normal file
212
ROADMAP.md
Normal file
|
|
@ -0,0 +1,212 @@
|
||||||
|
# Yavsc — Roadmap
|
||||||
|
|
||||||
|
> **Statut** : document vivant. Reflète l'état du repo et les décisions en cours.
|
||||||
|
>
|
||||||
|
> L'ancienne liste en français (jalons 1–5, 2016–2017) est archivée dans
|
||||||
|
> [`TODO.fr.md.archive`](./TODO.fr.md.archive) — tout ce qui en a été réalisé
|
||||||
|
> ou reformulé est ici.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🧭 Vision
|
||||||
|
|
||||||
|
Yavsc est une plateforme de **mise en relation client / fournisseur / coordinateur**,
|
||||||
|
spécialisable par activité, avec une **origine musicale**.
|
||||||
|
Origine du nom : *Yet Another Very Small Company*.
|
||||||
|
|
||||||
|
Le domaine est modélisé en **DDD** (cf. [`doc/ddd-exploration-2026-06-14.md`](./doc/ddd-exploration-2026-06-14.md))
|
||||||
|
et l'architecture globale est décrite dans [`doc/Architecture.md`](./doc/Architecture.md).
|
||||||
|
|
||||||
|
Trois principes non négociables traversent tous les jalons :
|
||||||
|
|
||||||
|
1. **Devis, pas facturation directe.** Le flux contractuel prime sur le flux
|
||||||
|
d'encaissement ; l'argent arrive seulement après accord signé.
|
||||||
|
2. **Open by design.** Le code des livrables et la plateforme sont sous licence
|
||||||
|
libre ; les workflows métier aboutissent à des livrables sous licence libre.
|
||||||
|
3. **Pas de MVP borné.** Le périmètre est complet dès la conception — les
|
||||||
|
jalons ne sont pas une découpe de fonctionnalités, mais une **séquence de
|
||||||
|
stabilisation**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🏗️ État de l'art (juin 2026)
|
||||||
|
|
||||||
|
### Périmètre technique
|
||||||
|
|
||||||
|
| Brique | Module | État |
|
||||||
|
|---|---|---|
|
||||||
|
| Backend ASP.NET | `Yavsc.Server`, `Yavsc.Web`, `Yavsc.Api`, `Yavsc.Org` | actif, build OK, cible .NET 10 |
|
||||||
|
| Domaine partagé | `Yavsc.Abstract` | actif |
|
||||||
|
| Blogs | `Yavsc.Blogs` | actif |
|
||||||
|
| Client chat (`PostIt`) | `PostIt` (Avalonia) + `PostIt.Android` / `PostIt.Browser` / `PostIt.Desktop` | actif, OIDC |
|
||||||
|
| CLI admin | `src/cli` | actif |
|
||||||
|
| Tests | `test/yavscTests` | présents, à densifier |
|
||||||
|
| Conteneurisation | `Dockerfile`, `Dockerfile.backend`, `docker-compose.yaml` | actif, image `pazof/yavsc-build-env` |
|
||||||
|
| CI | `.github/workflows/`, Dependabot (multi-ecosystems) | actif |
|
||||||
|
| Docs | `doc/Architecture.md`, `doc/ddd-exploration-2026-06-14.md` | frais (13–14 juin 2026) |
|
||||||
|
|
||||||
|
### Bounded Contexts identifiés
|
||||||
|
|
||||||
|
| # | BC | Module | Maturité |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 1 | Chat | `PostIt` | client riche + backend, OIDC |
|
||||||
|
| 2 | Profil & Identité | `Yavsc.Org` | en place |
|
||||||
|
| 3 | Activités Légales | `Yavsc.Org` (à séparer ?) | taxonomie présente |
|
||||||
|
| 4 | Blogs | `Yavsc.Blogs` | en place |
|
||||||
|
| 5 | Prestation | `Yavsc.Server` | cœur métier, à compléter |
|
||||||
|
| 6 | Paiements | `Yavsc.Server` | PayPal NVP/SOAP, **arrhes vs avance** à clarifier |
|
||||||
|
| 7 | Rencontre (mode 2) | à créer | pas démarré |
|
||||||
|
| 8 | Modération | `Yavsc.Org` / à séparer | workflow 2 étages, amorcé |
|
||||||
|
| 9 | Trust & Safety | à séparer | blacklist plateforme, à industrialiser |
|
||||||
|
| 10 | Conciliation | à créer | jalon 5, pas démarré |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🚦 Jalons
|
||||||
|
|
||||||
|
> Convention : `☐` à faire · `◐` en cours · `✔` livré
|
||||||
|
>
|
||||||
|
> Chaque jalon a un **critère de sortie** vérifiable.
|
||||||
|
|
||||||
|
### Jalon 0 — Fondations techniques *(en cours)*
|
||||||
|
|
||||||
|
> Cible : pouvoir parler du domaine sans se battre avec le runtime.
|
||||||
|
|
||||||
|
- ◐ Centralisation des versions NuGet (`Directory.Packages.props`) — **fait pour l'essentiel, à compléter**
|
||||||
|
- ◐ Conteneurisation de bout en bout (build env + run + compose)
|
||||||
|
- ☐ Tests d'intégration smoke par BC
|
||||||
|
- ☐ Découpage `Yavsc.Org` vs `Yavsc.Server` vs `Yavsc.Api` clarifié dans l'Architecture
|
||||||
|
- ☐ `CONTRIBUTING.md` (build, tests, conventions, DDD sessions)
|
||||||
|
|
||||||
|
**Critère de sortie** : `dotnet build` + `dotnet test` + `docker compose up` verts sur une machine vierge.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Jalon 1 — Prestation signée de bout en bout
|
||||||
|
|
||||||
|
> Cible : un projet client/fournisseur aboutit à un **devis signé par les deux parties**, traçable, avec notifications.
|
||||||
|
|
||||||
|
Sous-jalons du `TODO.fr.md.archive` repris ici :
|
||||||
|
|
||||||
|
- ◐ **Devis validé fournisseur → client** : notification + mise à disposition du devis signé
|
||||||
|
- ☐ **Accord client sur devis** : notification fournisseur + mise à disposition signature client + commentaire
|
||||||
|
- ☐ **Édition facture non acquittée** depuis mobile
|
||||||
|
- ☐ **Édition contrat** depuis mobile
|
||||||
|
- ☐ **Notification & mise à disposition contrat** pour le client
|
||||||
|
- ☐ **Signature contrat par le client**
|
||||||
|
- ☐ **Notification facture non acquittée** au client
|
||||||
|
- ☐ **Paiement du client** (arrhes ? — voir jalon 2)
|
||||||
|
- ☐ **Édition facture marquée acquittée + signée** par le fournisseur
|
||||||
|
- ☐ **Notification facture acquittée signée** au client
|
||||||
|
- ☐ **Évaluation de la prestation** (des deux côtés)
|
||||||
|
|
||||||
|
**Critère de sortie** : scénario E2E web + mobile, devis → signature croisée → contrat → facture, sans intervention manuelle d'un opérateur.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Jalon 2 — Espace personnel, blog opérationnel, marché ouvert
|
||||||
|
|
||||||
|
> Cible : un prestataire vit sur Yavsc (stocke, publie, est trouvé).
|
||||||
|
|
||||||
|
Repris du `TODO.fr.md.archive`, jalon 1 (sélection) + jalon 2 (interface) :
|
||||||
|
|
||||||
|
- ☐ **Gestion du profil utilisateur** Simple & Prestataire, sur **Android** (Web ✔)
|
||||||
|
- ☐ **Gestion de l'espace de stockage personnel** (Web, API web, Mobile)
|
||||||
|
- ☐ **Création d'une annonce**
|
||||||
|
- ☐ **Transformation annonce ↔ demande nominative**
|
||||||
|
- ☐ **Sélection d'une star** depuis le **mobile** (Web ✔)
|
||||||
|
- ☐ **Sélection DJ / chanteur / formation** (recherche par critères : date, lieu, tendance, taille, répertoire) depuis le **mobile**
|
||||||
|
- ☐ **Géocodeur de lieu** côté mobile
|
||||||
|
- ☐ **Géocodeur d'adresse postale** (Web + Mobile)
|
||||||
|
- ☐ **Évaluation des trajets**
|
||||||
|
- ☐ **Interface de gestion des collaborateurs** (sous-traitance — déjà amorcée dans `doc/Architecture.md`)
|
||||||
|
- ☐ **Migration de l'identifiant utilisateur** : `string` GUID → `long` auto-incrémenté (Npgsql)
|
||||||
|
- ☐ **Login with Twitter / PayPal**
|
||||||
|
- ☐ **Contrôle Web du rating**
|
||||||
|
- ☐ **Saisie et usage des disponibilités** (ponctuelles, récurrentes, congés)
|
||||||
|
- ☐ **Notifications structurelles** (impératives, par groupe)
|
||||||
|
- ☐ **Notifications aux posts, à l'arrivée d'un artiste, à une success story**
|
||||||
|
- ☐ **Construction du droit à l'envoi d'un message privé** (par destinataire, par accréditation, temporaire / définitif, par plage de temps, par validité d'un devis)
|
||||||
|
- ☐ **Paiement client du reste de la prestation**
|
||||||
|
- ☐ **Podcasts**
|
||||||
|
- ☐ **Personnalisation des blogs**
|
||||||
|
- ☐ **Monétisations**
|
||||||
|
- ☐ **Distribution de gold card / green card** (par un prestataire, donnant accès au chat privé)
|
||||||
|
- ☐ **Carte blanche** (délégation d'agenda, implique droit au chat privé)
|
||||||
|
- ☐ **Badges temporaires** (téléchargement unique, limité dans le temps, sans autre autorisation)
|
||||||
|
|
||||||
|
**Critère de sortie** : un utilisateur mobile peut publier une annonce, être sélectionné, signer, encaisser.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Jalon 3 — Commande générique & formulaires extensibles
|
||||||
|
|
||||||
|
> Cible : le système de prise de commande n'est plus codé en dur par activité.
|
||||||
|
|
||||||
|
- ☐ **Saisie du devis sur commande générique** : les commandes sont des *projets utilisateur* associés à des *listes de formulaires* spécialisables
|
||||||
|
- ☐ **Groupe de champs** avec titre, contenant des champs :
|
||||||
|
- ☐ Label
|
||||||
|
- ☐ Type de valeur
|
||||||
|
- ☐ Type de contrôle
|
||||||
|
- ☐ Liste de validateurs
|
||||||
|
- ☐ Invitation à la saisie
|
||||||
|
- ☐ **Saisie d'un devis à destination d'un invité** (envoi par email, contact local)
|
||||||
|
- ☐ **Paiement d'arrhes** (cf. décision arrhes vs avance à prendre en jalon 0/1)
|
||||||
|
|
||||||
|
**Critère de sortie** : ajouter une nouvelle activité (code APE, formulaire, contrôles) sans toucher au code du backend, par simple configuration.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Jalon 4 — Rencontre, géolocalisation, streaming
|
||||||
|
|
||||||
|
> Cible : Yavsc devient aussi un lieu de rencontre (Mode 2), pas seulement un outil de travail.
|
||||||
|
|
||||||
|
- ☐ **Aide à la rencontre physique** : carte interactive, geofencing, alertes
|
||||||
|
- ☐ **Activités secondaires** : spécialisation d'une activité, activités filles, *activité principale* (code APE)
|
||||||
|
- ☐ **Streaming vidéo pair-à-pair**
|
||||||
|
- ☐ **Streaming vidéo public**
|
||||||
|
|
||||||
|
**Critère de sortie** : un événement géolocalisé notifie ses participants confirmés à l'approche du point de rendez-vous.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Jalon 5 — Conciliation & réseau pro
|
||||||
|
|
||||||
|
> Cible : un conflit entre client et fournisseur a un chemin de résolution outillé.
|
||||||
|
|
||||||
|
- ☐ **Conciliation** : double vue client/fournisseur sur le dossier, indicateurs, *FrontOffice* tranche et propose un partage des torts
|
||||||
|
- ☐ **Réseau pro** : sous-traitance en cascade, une demande n'est validable que lorsque **tous les devis** dont elle dépend sont validés
|
||||||
|
|
||||||
|
**Critère de sortie** : un dossier en litige peut être instruit par un conciliateur sans échange d'emails en parallèle.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🔒 Hygiène transverse (à tous les jalons)
|
||||||
|
|
||||||
|
### Sécurité
|
||||||
|
|
||||||
|
- ☐ Quota filesystem par utilisateur
|
||||||
|
- ☐ Clés anti-forge sur toutes les interfaces Web
|
||||||
|
- ☐ Limites de taille des chaînes du modèle (là où ça manque)
|
||||||
|
- ☐ Revue des scopes OIDC (PostIt, API)
|
||||||
|
|
||||||
|
### Accessibilité
|
||||||
|
|
||||||
|
- ☐ Correction des libellés manquants / en anglais
|
||||||
|
|
||||||
|
### Réécritures techniques programmées
|
||||||
|
|
||||||
|
- ☐ Éviter la création de fichiers TeX intermédiaires pour la génération PDF
|
||||||
|
- ☐ Isolation `Yavsc.Api` (auth + rate limiting)
|
||||||
|
|
||||||
|
### Configurabilité
|
||||||
|
|
||||||
|
- ☐ Gestion de contenu des pages du site au format interne (non exposé au Web)
|
||||||
|
- Cible : `@Html.SiteContent<AccessRules>(id).Responsible` (style à finaliser)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🗃️ Archive
|
||||||
|
|
||||||
|
- [`TODO.fr.md.archive`](./TODO.fr.md.archive) — liste d'origine (2016–2017), conservée pour mémoire.
|
||||||
|
Tout ce qui en a été repris l'est dans le jalon correspondant ci-dessus.
|
||||||
|
|
@ -114,6 +114,26 @@ Rendu CSS/HTML — vert si `EstLibre`, orange sinon.
|
||||||
- **Base de données** : PostgreSQL (provider Npgsql)
|
- **Base de données** : PostgreSQL (provider Npgsql)
|
||||||
- **Frontend** : Razor views
|
- **Frontend** : Razor views
|
||||||
|
|
||||||
|
## Droits de yavsc
|
||||||
|
|
||||||
|
### Administration
|
||||||
|
|
||||||
|
Le groupe des administrateurs prend la charge de :
|
||||||
|
|
||||||
|
- la Gestion des licences
|
||||||
|
- la Gestion des groupes d'utilisateurs (les modérateurs, en particulier)
|
||||||
|
- la Gestion des projets
|
||||||
|
- la Gestion des utilisateurs
|
||||||
|
|
||||||
|
### Gestion des utilisateurs et des groupes
|
||||||
|
|
||||||
|
En supposant que les certificats de letsencrypt sont au groupe `www-data` ,
|
||||||
|
on peut créer l'utilisateur `yavsc` avec les droits suivants :
|
||||||
|
|
||||||
|
¨¨¨¨bash
|
||||||
|
sudo addgroup yavsc --system
|
||||||
|
sudo adduser --ingroup yavsc --add-extra-groups www-data \
|
||||||
|
--disabled-password --system yavsc
|
||||||
---
|
---
|
||||||
|
|
||||||
## À documenter ensuite
|
## À documenter ensuite
|
||||||
|
|
|
||||||
254
doc/ddd-exploration-2026-06-14.md
Normal file
254
doc/ddd-exploration-2026-06-14.md
Normal file
|
|
@ -0,0 +1,254 @@
|
||||||
|
# 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.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue