notazof/yavsc
1
0
Fork 0
Code Issues Pull requests Projects 1 Releases 3 Packages Wiki Activity Actions
yavsc/doc/architecture/decoupage-organisation.md
Paul Schneider 4ba1aa8858 doc: correct Yavsc.Blogs role (backend, not front) 
When documenting the per-project layout in the previous commit,
I described Yavsc.Blogs as 'Sous-domaine front web specifique
au blog', which is wrong: Yavsc.Blogs contains only ApiController
classes, services and models — no Razor views. The plan is to
deploy it as a headless backend API on a dedicated subdomain in
production, while the blog front (Razor views) stays in
Yavsc.Org to share rendering and auth.

Correct the description, the ASCII diagram, the table row, and
the 'why' paragraph accordingly.
2026-06-27 15:05:24 +01:00

5.6 KiB
Raw Blame History

Découpage des projets .NET

Récapitulatif : Le code est réparti en sept projets .NET sous src/, organisés par rôle : domaine partagé, bibliothèque métier, front web utilisateur-facing, API REST principale, backend API dédié aux blogs, front admin, et tests. Détail dans cette page, racine de l'architecture : Architecture.md.

Vue d'ensemble

                     ┌──────────────────────────────┐
                     │ Yavsc.Abstract (lib)         │
                     │ Modèles du domaine partagés  │
                     └──────────────┬───────────────┘
                                    │
                     ┌──────────────▼────────────────────┐
                     │ Yavsc.Server (lib)                │
                     │ Helpers, EF, services             │
                     └──────┬─────────┬──────────────┬───┘
                            │         │              │
              ┌─────────────▼──┐  ┌───▼──────────┐  ┌▼────────────────────┐
              │ Yavsc.Org (web)│  │ Yavsc.Api    │  │ Yavsc.Blogs (web)   │
              │ Front web      │  │ (web)        │  │ Backend API blogs   │
              │ + Identity-    │  │ API REST     │  │ (aucune vue Razor)  │
              │   Server       │  │ principale   │  │ déployé sur sous-   │
              │ + Razor views  │  │ JwtBearer    │  │ domaine en prod     │
              │ (héberge aussi │  └──────────────┘  └─────────────────────┘
              │  le front des  │
              │  blogs)        │
              └────────────────┘

Clients externes :
  - Yavsc.Web  : front admin / expérimentation, JwtBearer.
  - PostIt     : client desktop Avalonia (cf. postit-oidc.md).

Par projet

Projet Type SDK Rôle
Yavsc.Abstract Library Modèles du domaine partagés (entités, value objects, enums). Pas de dépendance framework.
Yavsc.Server Library Bibliothèque métier : DbContext, helpers PayPal/SMTP, services métier, modèles billing/blog.
Yavsc.Org ASP.NET Web Front web utilisateur-facing : Razor views, IdentityServer8 (OP), AccountController. Héberge aussi les vues (front) des blogs.
Yavsc.Api ASP.NET Web API REST JSON principale consommée par les clients externes (PostIt, …). JwtBearer auth.
Yavsc.Blogs ASP.NET Web Backend API headless dédié aux blogs (uniquement *ApiController + services + modèles — aucune vue Razor). Destiné à être déployé sur un sous-domaine en production, séparé du front web hébergé par Yavsc.Org.
Yavsc.Web ASP.NET Web Front admin / expérimentations, JwtBearer, référence Yavsc.Abstract et Yavsc.Server.
Yavsc.Org.Tests Test (xUnit) Tests d'isolation du front web (Yavsc.Org) — fakes, controller tests.

Pourquoi ce découpage

  • Yavsc.Abstract séparé de Yavsc.Server : permet aux clients externes (PostIt — projet Avalonia sous src/PostIt/) de partager les modèles DTO sans embarquer Entity Framework ni ASP.NET Core.
  • Yavsc.Server est une library, pas un web host : on peut tester les services sans démarrer Kestrel ; plusieurs fronts et backends consomment les mêmes helpers sans dupliquer.
  • Yavsc.Api séparé de Yavsc.Org : l'API REST principale est destinée aux clients headless (PostIt, intégrations tierces) ; elle n'a pas besoin des vues Razor ni d'IdentityServer. Inversement, le front web peut servir ses propres pages serveur sans exposer une API REST.
  • Yavsc.Blogs séparé en backend headless : le front des blogs (vues Razor) reste dans Yavsc.Org pour partager le rendu et l'auth avec le reste de l'application. Le backend, lui, est isolé dans son propre projet Yavsc.Blogs (uniquement des *ApiController + services + modèles, sans aucune vue Razor), destiné à être déployé sur un sous-domaine dédié en production — ex: blogs.yavsc.example — pour pouvoir scaler / restreindre l'API blog indépendamment du reste de la plateforme.

Conséquences pratiques

  • Une modification d'un modèle DDD dans Yavsc.Abstract peut casser plusieurs fronts et backends à la fois (Org, Api, Blogs, Web). C'est attendu ; les tests de Yavsc.Org.Tests doivent suivre.
  • Ajouter une route API dans Yavsc.Api n'implique pas de recompiler Yavsc.Org (et inversement).
  • Yavsc.Blogs et Yavsc.Org partagent le contexte EF via Yavsc.Server mais n'ont pas de dépendance l'un envers l'autre : la même base de données, deux hôtes distincts en production.
  • PostIt (sous src/PostIt/) ne référence que Yavsc.Abstract ; il n'embarque ni EF ni ASP.NET Core.

Voir aussi