Paul Schneider 74de6aa1d1 doc: split Architecture.md into per-topic pages

doc/Architecture.md was 436 lines and growing; this commit
extracts each non-trivial subject into its own page under
doc/architecture/ and reduces the root document to a table of
contents + transversal sections (vision, stack, admin rights).

New pages (under doc/architecture/):

- workflow-multi-parties.md : client / fournisseur /
  coordinateur roles, sous-traitance, project states, B2B/B2C,
  domaine musical production flow.
- domaine-musical.md : titres collaboratifs (formats, flux de
  production, contraintes de licence).
- licences.md : LicenceModele, CC/ODbL seed, badge projet,
  cycle de vie.
- domaines-activite.md : arbre des activites, Droit a la
  racine, DomaineActivite model.
- dictionnaires-metier.md : regle d'heritage, DictionnaireMetier
  + TermeMetier, cycle de vie d'un terme. Absorbs the previous
  doc/Dictionnaire.md draft.
- offres-frontmatter.md : ClasseFormulaire / ClasseDevis,
  OffreFournisseur, Demande, parsing YamlDotNet (introduit dans
  4034c399 Front matters). Absorbs the previous
  doc/Formulaires-devis.md and doc/Demande.md fragments.
- postit-oidc.md : documentation du client desktop PostIt,
  custom URI scheme (RFC 8252 §7.1), composants partages,
  plateformes, UX observable, persistance et reprise au boot,
  garanties testees.

Architecture.md (436 -> 66 lines) keeps the vision, the stack
overview, the admin rights section, and a TOC table pointing at
each detail page. The "A documenter ensuite" backlog is kept
at the end.

Cross-links are relative: from Architecture.md the links go
architecture/<page>.md; from inside doc/architecture/ they go
../Architecture.md or <sibling>.md.

2026-06-27 13:45:31 +01:00

2.2 KiB

Raw Blame History

Dictionnaires métier

Récapitulatif : Les dictionnaires sont des modèles publics de termes métier, validés par les modérateurs et copiés dans chaque projet (instantané, pas référence vivante). L'héritage suit l'arbre des activités. Détail dans cette page, racine de l'architecture : Architecture.md.

Principe

Les dictionnaires sont des modèles publics de termes métier, maintenus par les modérateurs et alimentés par les fournisseurs. Au moment de créer un projet, le dictionnaire est copié — c'est un instantané, pas une référence vivante.

Note historique : une première ébauche de cette page existait à doc/Dictionnaire.md. Elle a été absorbée ici.

Règle de résolution

Un projet hérite des dictionnaires de son activité et de tous ses ancêtres jusqu'à la racine.

Ainsi, les termes juridiques sont toujours disponibles, quel que soit le domaine du projet.

Le modèle de dictionnaire du contrat est le dictionnaire défini par l'activité ciblée par le client.

Dictionnaires juridiques

Les dictionnaires juridiques sont des modèles publics de termes juridiques, maintenus et alimentés par les modérateurs. Ils figurent à la racine de l'arbre (sous Droit) et profitent donc à toutes les activités par construction.

Ce dictionnaire juridique est simplement fondamental, par construction, c'est la base de tous les dictionnaires.

Modèle

DictionnaireMetier
  - Id, Nom
  - DomaineActiviteId (FK)
  - Langue                      ← attribut du dictionnaire entier

TermeMetier
  - Id
  - DictionnaireMetierId (FK)
  - Mot
  - Definition
  - StatutValidation            ← Proposé | Validé | Rejeté
  - ProposeParId (FK → ApplicationUser)
  - ValidéParId  (FK → ApplicationUser, nullable)

Cycle de vie d'un terme

Un fournisseur propose un terme dans son domaine et sa langue
Un modérateur valide → le terme intègre le dictionnaire public
À la création d'un projet, le dictionnaire est associé par copie

Voir aussi

Architecture.md — racine.
domaines-activite.md — l'arbre des activités qui justifie la règle d'héritage.

2.2 KiB Raw Blame History