yavsc/doc/architecture/domaines-activite.md

59 lines
1.8 KiB
Markdown
Raw Normal View History

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
# 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.