Files
Starseed/.claude/rules/architecture.md
Matthieu 711774425b docs(claude) : refactorise CLAUDE.md en index + extrait les regles dans .claude/rules/
- CLAUDE.md devient un index concis : contexte, stack, regles absolues
  numerotees, pointeurs vers les fichiers de regles detaillees via
  references @.claude/rules/*.md
- Les conventions detaillees (architecture, backend, frontend, testing,
  naming, git, workflow) sont extraites dans .claude/rules/ pour rester
  chargees a la demande sans gonfler le context du CLAUDE.md principal
- Ajoute la regle absolue "Ne jamais mentionner Claude/IA dans commits
  ou PR" (point 10) pour garder l'historique git signe par l'utilisateur
2026-04-23 11:02:04 +02:00

67 lines
2.9 KiB
Markdown

# Architecture — Modular Monolith DDD
## Principe fondamental
Le **backend est la source de verite unique**. Il dicte :
- Quels modules sont actifs (`config/modules.php`)
- L'organisation de la sidebar (`config/sidebar.php`, decouplee des modules)
Le frontend scanne `modules/*/` comme layers Nuxt et consomme l'API pour la navigation. Il ne decide rien.
## Endpoints API cles
- `GET /api/version` (public) — version de l'app
- `GET /api/modules` (public) — IDs des modules actifs
- `GET /api/sidebar` (public) — sections filtrees par modules actifs + `disabledRoutes` (items dont le module owner est inactif)
- `GET /api/me` (auth) — user courant
## Arborescence minimale (detail complet : @README.md)
```
src/
Shared/ # Noyau technique partage (Domain/, Application/Bus/, Infrastructure/ApiPlatform/)
Module/
Core/ # Module obligatoire (auth, users)
CoreModule.php # ID, LABEL, REQUIRED, permissions()
Domain/ Application/ Infrastructure/
Commercial/ # Exemple d'autre module
frontend/
app/ # Shell (layouts, middlewares)
shared/ # Code inter-modules (composables, stores, utils)
modules/ # Layers Nuxt auto-detectes
core/ commercial/
```
## Declaration d'un module
Chaque module expose un `*Module.php` avec :
- `ID` (snake_case, ex: `commercial`, `gestion_rh`)
- `LABEL`
- `REQUIRED` (bool)
- Methode statique `permissions()` retournant les RBAC du module
## Activer / desactiver un module
Editer uniquement `config/modules.php` (commenter la ligne). Cascade automatique :
1. `/api/modules` ne retourne plus l'ID
2. `/api/sidebar` filtre les items `module: '<id>'` et supprime les sections vides
3. Middleware front `modules.global.ts` redirige toute navigation vers une route desactivee
4. Le code reste dans le bundle (layer auto-detecte) → reactivation instantanee sans rebuild
## Reorganiser la sidebar
Editer uniquement `config/sidebar.php`. Le code des modules n'est pas touche — seule la place des items change. Chaque item reference son module owner via la cle `module`.
## Communication inter-modules
**Interdit** : import direct d'une classe d'un autre module.
**Autorise** :
- Via `Shared/Domain/Contract/` (interfaces : `UserResolverInterface`, `TenantAwareInterface`...)
- Via domain events (`Shared/Domain/Event/DomainEventInterface`)
## Migrations
- **Par defaut** : `src/Module/<Module>/Infrastructure/Doctrine/Migrations/` (namespace modulaire)
- **Exception** : les migrations d'initialisation critiques (setup user, RBAC, seed de base) vivent au namespace racine `DoctrineMigrations` dans `migrations/`.
- Raison : avec plusieurs `migrations_paths`, Doctrine Migrations 3.x trie par FQCN alphabetique et non par version timestamp → ordre incorrect entre namespaces sur base vide.
- A supprimer quand un `MigrationsComparator` custom ou un upgrade Doctrine resoudra le tri.