Application Design — SlpModularCms.Api

Dit document consolideert het volledige applicatie-ontwerp voor de modulaire CMS API.

1. Architectuur Overzicht

De applicatie volgt een modulaire Clean Architecture structuur waarbij het Core Framework de centrale spil is. Modules zijn onafhankelijke projecten (.csproj) of DLL's die via een hybride laad-strategie worden geïntegreerd.

Kleurgecodeerd Diagram:

graph LR
    subgraph "Core Phase"
        Core[Core Framework]
        ID[Identity Subsysteem]
    end
    
    subgraph "Module Phase"
        Avail[Availability Module]
        Other[External Modules]
    end
    
    Shell[API Shell]
    
    Shell --> Core
    Shell --> Avail
    Shell -.-> Other
    
    Avail --> Core
    Other -.-> Core
    
    style Core fill:#BBDEFB,stroke:#1565C0,color:#000
    style ID fill:#E3F2FD,stroke:#1565C0,color:#000
    style Shell fill:#C8E6C9,stroke:#2E7D32,color:#000
    style Avail fill:#FFF59D,stroke:#F57F17,color:#000

2. Belangrijkste Componenten

Zie de gedetailleerde beschrijvingen in components.md.

Core: Gedeelde logica, Identity en interfaces.
Availability Module: MVP placeholder voor statuscontrole.
API Shell: Host en orchestrator.

3. Interfaces & Services

Zie component-methods.md en services.md.

IModule: Het contract voor module-integratie.
IAuthService / IUserService: Beheer van identiteit en hiërarchische RBAC.
IAvailabilityService: Controleert of de API of specifieke modules operationeel zijn.

4. Ontwerpbeslissingen (Besloten in Plan)

Hybride Module Loading: Core modules worden statisch geladen voor performance en type-safety; optionele modules kunnen dynamisch worden toegevoegd.
Identity in Core: Voor de MVP is Identity een integraal onderdeel van het framework om complexe autorisatie-hiërarchieën (Owner > Admin > User) eenvoudiger te borgen.
Eenvoudige Projectstructuur: Per module wordt één project gebruikt om de complexiteit laag te houden, met interne folders voor separation of concerns.
Policy-Based RBAC: Gebruik van standaard ASP.NET Core AuthorizationPolicy voor het afdwingen van de rol-hiërarchie.

5. Volgende Stappen

Op basis van dit ontwerp wordt de applicatie opgesplitst in Units of Work in de volgende fase (Units Generation).

2.4 KiB Raw Blame History