Paul Schneider
74de6aa1d1
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.
59 lines
1.8 KiB
Markdown
59 lines
1.8 KiB
Markdown
# Domaines d'activité
|
|
|
|
> **Récapitulatif** : Yavsc organise ses activités en arbre, avec
|
|
> `Droit` à la racine pour rendre les termes juridiques
|
|
> disponibles partout. Pas de booléen "transversal" : la
|
|
> transversalité découle de la position dans l'arbre. Détail dans
|
|
> cette page, racine de l'architecture : [Architecture.md](../Architecture.md).
|
|
|
|
## Hiérarchie
|
|
|
|
Les activités sont organisées en arbre. Chaque activité peut avoir
|
|
une activité parente d'ordre plus général :
|
|
|
|
```
|
|
Droit ← racine, ancêtre commun
|
|
├── Musique
|
|
│ ├── Jazz
|
|
│ ├── Classique
|
|
│ └── ...
|
|
├── Graphisme
|
|
├── BTP
|
|
└── ...
|
|
```
|
|
|
|
Le domaine **Droit** est positionné à la racine — *nul n'est
|
|
censé ignorer la loi*. Sa position structurelle rend ses
|
|
dictionnaires naturellement disponibles dans tous les projets,
|
|
sans attribut spécial.
|
|
|
|
## Modèle `DomaineActivite`
|
|
|
|
```
|
|
DomaineActivite
|
|
- Id, Nom
|
|
- ParentId (FK → DomaineActivite, nullable)
|
|
```
|
|
|
|
Pas de booléen `EstTransversal` — la transversalité est une
|
|
conséquence de la position dans l'arbre, pas un attribut
|
|
explicite.
|
|
|
|
## Conséquences sur les autres référentiels
|
|
|
|
Cette arborescence irrigue :
|
|
|
|
- les **dictionnaires métier** (cf. [dictionnaires-metier.md](dictionnaires-metier.md)) :
|
|
un projet hérite des dictionnaires de ses ancêtres.
|
|
- les **classes de formulaire et de devis** (cf.
|
|
[offres-frontmatter.md](offres-frontmatter.md)) : un fournisseur
|
|
rattaché à `Musique → Jazz` a accès aux modèles de son
|
|
activité et de ses ancêtres.
|
|
|
|
## Voir aussi
|
|
|
|
- [Architecture.md](../Architecture.md) — racine.
|
|
- [dictionnaires-metier.md](dictionnaires-metier.md) — règle
|
|
d'héritage en arbre.
|
|
- [offres-frontmatter.md](offres-frontmatter.md) — modèle
|
|
canonique nom/valeur pour formulaires et devis.
|