Initial commit with inital CMS
This commit is contained in:
@@ -0,0 +1,69 @@
|
||||
# Application Design Plan — SlpModularCms.Api
|
||||
|
||||
## Stap 1: Analyse & Voorbereiding
|
||||
- [x] Requirements en User Stories analyseren op component-grenzen.
|
||||
- [x] Architecturale stijl (Clean Architecture) vertalen naar componenten.
|
||||
|
||||
## Stap 2: Ontwerp van Componenten & Verantwoordelijkheden
|
||||
- [x] **Core Framework Component**: Verantwoordelijk voor module-registratie, gedeelde interfaces en cross-cutting concerns.
|
||||
- [x] **Identity Module**: Gebruikersbeheer, authenticatie en de hiërarchische RBAC logica.
|
||||
- [x] **Availability Module**: De stub implementatie voor beschikbaarheidscontrole.
|
||||
- [x] **Web API Shell**: Het startpunt dat alles samenbrengt en Swagger host.
|
||||
- [x] Genereer `aidlc-docs/inception/application-design/components.md`.
|
||||
|
||||
## Stap 3: Interface & Method Design
|
||||
- [x] Definieer `IModule` contract voor module-initialisatie.
|
||||
- [x] Definieer `IAvailabilityService` contract.
|
||||
- [x] Definieer Identity services (bijv. `IUserService`, `IAuthService`).
|
||||
- [x] Genereer `aidlc-docs/inception/application-design/component-methods.md`.
|
||||
|
||||
## Stap 4: Service Orchestratie & Dependency Mapping
|
||||
- [x] Ontwerp het mechanisme voor het laden van modules (Dependency Injection patronen).
|
||||
- [x] Map de afhankelijkheden tussen Core, Modules en de API Shell.
|
||||
- [x] Genereer `aidlc-docs/inception/application-design/services.md`.
|
||||
- [x] Genereer `aidlc-docs/inception/application-design/component-dependency.md`.
|
||||
|
||||
## Stap 5: Consolidatie
|
||||
- [x] Genereer `aidlc-docs/inception/application-design/application-design.md`.
|
||||
- [x] Valideer op consistentie met de hiërarchische rollen (RBAC) en modulaire eisen.
|
||||
|
||||
---
|
||||
|
||||
## Vragen voor Application Design
|
||||
|
||||
Beantwoord de volgende vragen om het ontwerp te verfijnen. Vul je keuze in na de `[Answer]:` tag.
|
||||
|
||||
### Vraag 1: Module Loading Strategie
|
||||
Hoe moeten modules technisch geladen worden door het raamwerk?
|
||||
A) Statische referentie: Modules zijn project-referenties in de API Shell (.csproj references).
|
||||
B) Dynamisch laden: Modules worden als DLL's uit een folder geladen bij opstarten.
|
||||
C) Hybride: Statische referentie voor core modules, dynamisch voor optionele modules.
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: C
|
||||
|
||||
### Vraag 2: Identity Locatie
|
||||
Wordt Identity gezien als een kernonderdeel van het framework of als een uitwisselbare module?
|
||||
A) Kernonderdeel (Core): Altijd aanwezig, diep geïntegreerd.
|
||||
B) Module: Een aparte .csproj die optioneel/vervangbaar is.
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: A
|
||||
|
||||
### Vraag 3: Clean Architecture Diepte
|
||||
Welke project-structuur heeft de voorkeur voor de modules?
|
||||
A) Eenvoudig: Eén project per module met interne folderstructuur (API, Logic, Data).
|
||||
B) Volledige Clean Architecture: Meerdere projecten per module (bijv. Identity.Domain, Identity.Application, Identity.Infrastructure).
|
||||
C) API-First: Modules bevatten alleen Controllers en Application logica, maken gebruik van gedeelde Core Data laag.
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: A
|
||||
|
||||
### Vraag 4: RBAC Implementatie
|
||||
Hoe moet de hiërarchische RBAC (Owner > Admin > User) technisch worden afgedwongen?
|
||||
A) ASP.NET Core Policies: Gebruik maken van `AuthorizationPolicy` die de hiërarchie controleert.
|
||||
B) Custom Middleware: Een interceptor die bij elk request de rollen en hiërarchie valideert.
|
||||
C) Service-level checks: De logica wordt handmatig in de services aangeroepen voor elke actie.
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: A
|
||||
@@ -0,0 +1,142 @@
|
||||
# Execution Plan
|
||||
|
||||
## Detailed Analysis Summary
|
||||
|
||||
### Project Context
|
||||
- **Project Type**: Greenfield
|
||||
- **Primary Objective**: Bouwen van een modulaire CMS API met hiërarchische RBAC en beschikbaarheidscontrole stub.
|
||||
- **Architectuur**: Modulair (.csproj per module), Clean Architecture / Gelaagde architectuur.
|
||||
|
||||
### Change Impact Assessment
|
||||
- **User-facing changes**: Ja — RESTful endpoints voor authenticatie, gebruikersbeheer en modulebeheer.
|
||||
- **Structural changes**: Ja — Opzetten van het module-laad-mechanisme en de core framework structuur.
|
||||
- **Data model changes**: Ja — Identity modellen (User, Role) en module-registraties.
|
||||
- **API changes**: Ja — REST contracten voor alle MVP functionaliteit.
|
||||
- **NFR impact**: Ja — Security (JWT), Modulairiteit (DI), Onderhoudbaarheid (PBT).
|
||||
|
||||
### Risk Assessment
|
||||
- **Risk Level**: Medium
|
||||
- **Rollback Complexity**: Easy (Git-based development)
|
||||
- **Testing Complexity**: Moderate (Vereist integratietesten voor de hiërarchische rollen en module isolatie)
|
||||
|
||||
## Workflow Visualization
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start(["User Request"])
|
||||
|
||||
subgraph INCEPTION["<font color='#000000'>🔵 INCEPTION PHASE</font>"]
|
||||
WD["Workspace Detection<br/><b>COMPLETED</b>"]
|
||||
RE["Reverse Engineering<br/><b>SKIPPED (Greenfield)</b>"]
|
||||
RA["Requirements Analysis<br/><b>COMPLETED</b>"]
|
||||
US["User Stories<br/><b>COMPLETED</b>"]
|
||||
WP["Workflow Planning<br/><b>COMPLETED</b>"]
|
||||
AD["Application Design<br/><b>EXECUTE</b>"]
|
||||
UG["Units Generation<br/><b>EXECUTE</b>"]
|
||||
end
|
||||
|
||||
subgraph CONSTRUCTION["<font color='#000000'>🟢 CONSTRUCTION PHASE</font>"]
|
||||
FD["Functional Design<br/>(per unit)<br/><b>EXECUTE</b>"]
|
||||
NFRA["NFR Requirements<br/>(per unit)<br/><b>EXECUTE</b>"]
|
||||
NFRD["NFR Design<br/>(per unit)<br/><b>EXECUTE</b>"]
|
||||
ID["Infrastructure Design<br/>(per unit)<br/><b>SKIP</b>"]
|
||||
CG["Code Generation<br/>(Planning + Generation)<br/><b>EXECUTE</b>"]
|
||||
BT["Build and Test<br/><b>EXECUTE</b>"]
|
||||
end
|
||||
|
||||
subgraph OPERATIONS["<font color='#000000'>🟡 OPERATIONS PHASE</font>"]
|
||||
OPS["Operations<br/><b>PLACEHOLDER</b>"]
|
||||
end
|
||||
|
||||
Start --> WD
|
||||
WD --> RA
|
||||
RA --> US
|
||||
US --> WP
|
||||
WP --> AD
|
||||
AD --> UG
|
||||
UG --> FD
|
||||
FD --> NFRA
|
||||
NFRA --> NFRD
|
||||
NFRD --> CG
|
||||
CG -.->|Volgende Unit| FD
|
||||
CG --> BT
|
||||
BT --> End(["Complete"])
|
||||
|
||||
style WD fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style RA fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style US fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style WP fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style AD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style UG fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style FD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style NFRA fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style NFRD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style ID fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
|
||||
style CG fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style BT fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style OPS fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
|
||||
style RE fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
|
||||
style Start fill:#CE93D8,stroke:#6A1B9A,stroke-width:3px,color:#000
|
||||
style End fill:#CE93D8,stroke:#6A1B9A,stroke-width:3px,color:#000
|
||||
style INCEPTION fill:#BBDEFB,stroke:#1565C0,stroke-width:2px,color:#000000
|
||||
style CONSTRUCTION fill:#C8E6C9,stroke:#2E7D32,stroke-width:2px,color:#000000
|
||||
style OPERATIONS fill:#FFF59D,stroke:#F57F17,stroke-width:2px,color:#000000
|
||||
|
||||
linkStyle default stroke:#333333,stroke-width:2.5px
|
||||
linkStyle 10 stroke:#333333,stroke-width:2.5px,stroke-dasharray: 5 5
|
||||
```
|
||||
|
||||
### Text Alternative
|
||||
Phase 1: INCEPTION
|
||||
- Stage 1: Workspace Detection (COMPLETED)
|
||||
- Stage 2: Reverse Engineering (SKIPPED)
|
||||
- Stage 3: Requirements Analysis (COMPLETED)
|
||||
- Stage 4: User Stories (COMPLETED)
|
||||
- Stage 5: Workflow Planning (COMPLETED)
|
||||
- Stage 6: Application Design (EXECUTE)
|
||||
- Stage 7: Units Generation (EXECUTE)
|
||||
|
||||
Phase 2: CONSTRUCTION
|
||||
- Stage 8: Functional Design (EXECUTE per unit)
|
||||
- Stage 9: NFR Requirements (EXECUTE per unit)
|
||||
- Stage 10: NFR Design (EXECUTE per unit)
|
||||
- Stage 11: Infrastructure Design (SKIP)
|
||||
- Stage 12: Code Generation (EXECUTE per unit)
|
||||
- Stage 13: Build and Test (EXECUTE)
|
||||
|
||||
Phase 3: OPERATIONS
|
||||
- Stage 14: Operations (PLACEHOLDER)
|
||||
|
||||
## Phases to Execute
|
||||
|
||||
### 🔵 INCEPTION PHASE
|
||||
- [x] Workspace Detection (COMPLETED)
|
||||
- [x] Requirements Analysis (COMPLETED)
|
||||
- [x] User Stories (COMPLETED)
|
||||
- [x] Workflow Planning (COMPLETED)
|
||||
- [x] Application Design - VOLTOOID
|
||||
- [x] Units Generation - VOLTOOID
|
||||
|
||||
### 🟢 CONSTRUCTION PHASE
|
||||
- [x] Functional Design — VOLTOOID
|
||||
- [x] NFR Requirements — VOLTOOID
|
||||
- [x] NFR Design — VOLTOOID
|
||||
- [ ] Infrastructure Design - SKIP
|
||||
- [x] Code Generation — VOLTOOID
|
||||
- [x] Build and Test — VOLTOOID
|
||||
|
||||
### 🟡 OPERATIONS PHASE
|
||||
- [ ] Operations - PLACEHOLDER
|
||||
- **Rationale**: Toekomstige uitbreiding voor deployment en monitoring.
|
||||
|
||||
## Success Criteria
|
||||
- **Primary Goal**: Een functioneel raamwerk met een modulaire architectuur en werkend gebruikersbeheer.
|
||||
- **Key Deliverables**:
|
||||
- API Framework met module loading.
|
||||
- Identity/Auth module met hiërarchische rollen.
|
||||
- Beschikbaarheidscontrole stub.
|
||||
- Swagger documentatie.
|
||||
- **Quality Gates**:
|
||||
- Alle unit tests passeren.
|
||||
- Security baseline regels zijn toegepast.
|
||||
- PBT tests voor token/mapping logica zijn succesvol.
|
||||
@@ -0,0 +1,131 @@
|
||||
# Story Generation Plan — SlpModularCms.Api
|
||||
|
||||
## Uitvoeringsplan
|
||||
|
||||
### Stap 1: Persona's definiëren
|
||||
- [x] Eigenaar (Owner) persona aanmaken
|
||||
- [x] Beheerder (Administrator) persona aanmaken
|
||||
- [x] Gebruiker (User) persona aanmaken
|
||||
|
||||
### Stap 2: User Stories genereren per domein
|
||||
- [x] Authenticatie stories (login, token refresh, logout)
|
||||
- [x] Gebruikersbeheer stories (aanmaken, bewerken, verwijderen gebruikers)
|
||||
- [x] Autorisatie stories (rolbeheer, bevoegdheidsgrenzen)
|
||||
- [x] Module stories (module laden, module uitschakelen)
|
||||
- [x] Beschikbaarheidscontrole stories (placeholder/stub interactie)
|
||||
|
||||
### Stap 3: Acceptatiecriteria toevoegen
|
||||
- [x] Acceptatiecriteria per story definiëren (INVEST-compliant)
|
||||
|
||||
### Stap 4: Feature-story mapping
|
||||
- [x] Elke story koppelen aan het relevante feature-domein (Authenticatie, Gebruikersbeheer, Autorisatie, Setup, Modules, Beschikbaarheidscontrole)
|
||||
|
||||
### Stap 5: Persona-story mapping
|
||||
- [x] Elke story koppelen aan relevante persona('s) (Eigenaar, Beheerder, Gebruiker)
|
||||
|
||||
### Stap 6: Artifacts opslaan
|
||||
- [x] `aidlc-docs/inception/user-stories/stories.md` aanmaken
|
||||
- [x] `aidlc-docs/inception/user-stories/personas.md` aanmaken
|
||||
|
||||
---
|
||||
|
||||
## Vragen voor Story Planning
|
||||
|
||||
Beantwoord elke vraag door de letter van jouw keuze in te vullen na de `[Answer]:` tag.
|
||||
|
||||
---
|
||||
|
||||
### Vraag 1: Story breakdown aanpak
|
||||
Hoe moeten de user stories worden georganiseerd?
|
||||
|
||||
A) Feature-gebaseerd — stories gegroepeerd per systeemfunctionaliteit (authenticatie, gebruikersbeheer, modules)
|
||||
B) Persona-gebaseerd — stories gegroepeerd per gebruikerstype (Eigenaar, Beheerder, Gebruiker)
|
||||
C) User Journey-gebaseerd — stories volgen de workflow van een gebruiker van begin tot eind
|
||||
D) Epic-gebaseerd — hiërarchische structuur met epics en sub-stories
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
---
|
||||
|
||||
### Vraag 2: Story granulariteit
|
||||
Hoe gedetailleerd moeten de user stories zijn?
|
||||
|
||||
A) Hoog niveau — epics met globale beschrijvingen, details komen later
|
||||
B) Standaard — "Als [rol] wil ik [actie] zodat [doel]" met basisacceptatiecriteria
|
||||
C) Gedetailleerd — uitgebreide acceptatiecriteria met edge cases en foutscenario's
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: B
|
||||
|
||||
---
|
||||
|
||||
### Vraag 3: Gebruiker (User) rol — specifieke rechten
|
||||
De requirements vermelden dat Gebruikers "configureerbare rechten per klant" hebben. Welke standaard rechten moet een Gebruiker hebben in de MVP (voordat een Beheerder iets aanpast)?
|
||||
|
||||
A) Alleen lezen — Gebruiker kan alleen content bekijken, niets aanpassen
|
||||
B) Beperkt bewerken — Gebruiker kan eigen profiel en toegewezen content bewerken
|
||||
C) Geen rechten — Gebruiker heeft standaard geen rechten totdat een Beheerder ze instelt
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: X, Alleen lezen en eigen profiel bewerken.
|
||||
|
||||
---
|
||||
|
||||
### Vraag 4: Eigenaarschap overdracht
|
||||
Hoe moet eigenaarschap overdracht werken?
|
||||
|
||||
A) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar wordt automatisch Beheerder
|
||||
B) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar behoudt ook de Eigenaar rol (meerdere eigenaars mogelijk)
|
||||
C) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar kiest zelf welke rol hij behoudt
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: B
|
||||
|
||||
---
|
||||
|
||||
### Vraag 5: Wachtwoord reset / initieel wachtwoord
|
||||
Hoe wordt het initiële wachtwoord van een nieuwe gebruiker ingesteld?
|
||||
|
||||
A) Beheerder/Eigenaar stelt een tijdelijk wachtwoord in — gebruiker moet dit wijzigen bij eerste login
|
||||
B) Beheerder/Eigenaar stelt een permanent wachtwoord in — geen verplichte wijziging
|
||||
C) Systeem stuurt een uitnodigingslink per e-mail — gebruiker stelt zelf wachtwoord in
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
---
|
||||
|
||||
### Vraag 6: Refresh token gedrag
|
||||
Hoe moeten refresh tokens werken?
|
||||
|
||||
A) Refresh token is eenmalig bruikbaar — na gebruik wordt een nieuw refresh token uitgegeven (rotation)
|
||||
B) Refresh token is herbruikbaar tot vervaldatum — geen rotation
|
||||
C) Refresh token vervalt bij uitloggen en bij inactiviteit na een configureerbare periode
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
---
|
||||
|
||||
### Vraag 7: Eerste Eigenaar aanmaken
|
||||
Hoe wordt de eerste Eigenaar van een nieuwe installatie aangemaakt? (Er is geen andere Eigenaar/Beheerder om dit te doen)
|
||||
|
||||
A) Via een seed/migratie script dat bij eerste deployment wordt uitgevoerd
|
||||
B) Via een speciaal setup-endpoint dat alleen beschikbaar is als er nog geen Eigenaar bestaat
|
||||
C) Via configuratie in appsettings (e-mail + wachtwoord bij eerste start)
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: X, Optie A of B, wat is het handigste? Optie A zou ook kunnen als directe aanpassing in database en dan een Wachtwoord vergeten optie
|
||||
|
||||
---
|
||||
|
||||
### Vraag 8: Module rechten voor Gebruikers
|
||||
Kunnen Gebruikers rechten krijgen die specifiek zijn per module?
|
||||
|
||||
A) Ja — modules kunnen eigen rechten definiëren die een Beheerder/Eigenaar aan Gebruikers kan toekennen
|
||||
B) Nee — rechten zijn globaal voor de hele API, niet per module
|
||||
C) Nog niet in MVP — architectuur moet het later mogelijk maken
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: A
|
||||
+58
@@ -0,0 +1,58 @@
|
||||
# Story Planning Verduidelijkingsvragen — SlpModularCms.Api
|
||||
|
||||
Er zijn twee antwoorden die verdere verduidelijking nodig hebben voordat we kunnen doorgaan.
|
||||
|
||||
---
|
||||
|
||||
## Verduidelijking 1: Gebruiker (User) standaard rechten (Vraag 3)
|
||||
|
||||
Je antwoordde: *"Alleen lezen en eigen profiel bewerken"*
|
||||
|
||||
Dit combineert twee aspecten: leesrechten voor content én het bewerken van het eigen profiel.
|
||||
Om de user stories correct te kunnen schrijven, moet ik weten hoe dit precies werkt.
|
||||
|
||||
### Verduidelijkingsvraag 1a
|
||||
Wat mag een Gebruiker standaard lezen (zonder dat een Beheerder iets instelt)?
|
||||
|
||||
A) Alle content die beschikbaar is in de API (publieke en beveiligde content)
|
||||
B) Alleen content die expliciet aan de gebruiker is toegewezen door een Beheerder
|
||||
C) Alleen publieke content — beveiligde content vereist expliciete toewijzing
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
---
|
||||
|
||||
### Verduidelijkingsvraag 1b
|
||||
Wat mag een Gebruiker bewerken aan zijn eigen profiel?
|
||||
|
||||
A) Alleen wachtwoord wijzigen
|
||||
B) Wachtwoord + weergavenaam / profielinformatie
|
||||
C) Wachtwoord + alle profielgegevens behalve e-mailadres en rol
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
---
|
||||
|
||||
## Verduidelijking 2: Eerste Eigenaar aanmaken (Vraag 7)
|
||||
|
||||
Je vroeg: *"Optie A of B, wat is het handigste?"*
|
||||
|
||||
Hier is mijn advies:
|
||||
|
||||
**Optie A (seed/migratie script)** is het meest gebruikelijk bij .NET projecten met EF Core. Het wordt automatisch uitgevoerd bij `dotnet ef database update` of bij de eerste start van de applicatie. Nadeel: de credentials staan in configuratie of code.
|
||||
|
||||
**Optie B (setup-endpoint)** is gebruiksvriendelijker — je navigeert naar `/api/setup` en vult de gegevens in via een API call. Het endpoint verdwijnt automatisch zodra er een Eigenaar bestaat. Dit is veiliger omdat er geen credentials in configuratiebestanden staan.
|
||||
|
||||
**Mijn aanbeveling**: Optie B — het setup-endpoint is veiliger, gebruiksvriendelijker en past beter bij een API-first aanpak.
|
||||
|
||||
### Verduidelijkingsvraag 2
|
||||
Welke aanpak kies je voor het aanmaken van de eerste Eigenaar?
|
||||
|
||||
A) Seed/migratie script (Optie A) — automatisch bij eerste deployment via EF Core seed
|
||||
B) Setup-endpoint (Optie B) — speciaal `/api/setup` endpoint, alleen beschikbaar als er nog geen Eigenaar bestaat (aanbevolen)
|
||||
C) Combinatie — seed script voor development/testing, setup-endpoint voor productie
|
||||
X) Andere (beschrijf na [Answer]: tag)
|
||||
|
||||
[Answer]: C
|
||||
@@ -0,0 +1,56 @@
|
||||
# Units of Work Plan — SlpModularCms.Api
|
||||
|
||||
Dit plan beschrijft hoe we de CMS API gaan opsplitsen in logische eenheden (Units of Work) voor de implementatie.
|
||||
|
||||
## Stap 1: Systeem Decompositie
|
||||
- [x] Analyseer `application-design.md` om de eenheden te identificeren.
|
||||
- [x] Definieer de grenzen tussen het Core framework en de modules.
|
||||
|
||||
## Stap 2: Genereren van Unit Artifacts
|
||||
- [x] Genereer `aidlc-docs/inception/application-design/unit-of-work.md`.
|
||||
- [x] Genereer `aidlc-docs/inception/application-design/unit-of-work-dependency.md`.
|
||||
- [x] Genereer `aidlc-docs/inception/application-design/unit-of-work-story-map.md`.
|
||||
- [x] Documenteer de mappenstructuur en project-indeling (Greenfield).
|
||||
|
||||
## Stap 3: Validatie
|
||||
- [x] Controleer of alle User Stories zijn toegewezen aan een unit.
|
||||
- [x] Valideer de afhankelijkheden (geen circulaire afhankelijkheden).
|
||||
|
||||
---
|
||||
|
||||
## Vragen voor Units Generation
|
||||
|
||||
Beantwoord de volgende vragen om de decompositie te verfijnen. Vul je keuze in na de `[Answer]:` tag.
|
||||
|
||||
### Vraag 1: Ontwikkelvolgorde
|
||||
In welke volgorde wil je de eenheden ontwikkelen?
|
||||
A) Sequentieel: Eerst de volledige Core, dan de Availability module, dan de API Shell.
|
||||
B) Incrementeel: Een minimale Core, direct gevolgd door de Availability module om de orkestratie te testen.
|
||||
C) Parallel: (Niet aanbevolen voor solo-ontwikkeling, maar mogelijk voor de opzet).
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: A
|
||||
|
||||
### Vraag 2: Unit Granulariteit
|
||||
Hoe fijnmazig moeten de eenheden zijn voor de "Construction Phase"?
|
||||
A) Grofmazig: Eén unit voor de hele Core (inclusief Identity en RBAC).
|
||||
B) Fijnmazig: Identity apart van de Core Base (interfaces/cross-cutting).
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: B
|
||||
|
||||
### Vraag 3: Story Mapping Strategie
|
||||
Sommige stories overspannen meerdere technische lagen. Hoe moeten we deze mappen?
|
||||
A) Primary Unit: Map de story naar de unit waar de meeste logica zit (bijv. US-USER-01 naar Identity).
|
||||
B) Split Story: Deel de story op in technische sub-taken per unit (verhoogt administratie).
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: B
|
||||
|
||||
### Vraag 4: Project Creatie (Greenfield)
|
||||
Moeten alle .csproj bestanden in één keer worden aangemaakt in de eerste unit, of pas wanneer de unit aan de beurt is?
|
||||
A) Alles vooraf: Creëer de hele solution structuur in Unit 1.
|
||||
B) Just-in-time: Creëer projecten alleen wanneer de betreffende unit wordt geïmplementeerd.
|
||||
X) Anders: ...
|
||||
|
||||
[Answer]: B
|
||||
@@ -0,0 +1,27 @@
|
||||
# User Stories Assessment — SlpModularCms.Api
|
||||
|
||||
## Request Analyse
|
||||
- **Origineel verzoek**: Een modulaire CMS API bouwen met authenticatie, autorisatie (hiërarchische rollen) en gebruikersbeheer als MVP
|
||||
- **Gebruikersimpact**: Direct — meerdere gebruikerstypes (Eigenaar, Beheerder, Gebruiker) met verschillende rechten en workflows
|
||||
- **Complexiteitsniveau**: Complex — hiërarchische rollen, modulaire architectuur, beschikbaarheidscontrole placeholder
|
||||
- **Stakeholders**: Ontwikkelaar (API-bouwer), klanten (eindgebruikers van de CMS), toekomstige module-ontwikkelaars
|
||||
|
||||
## Assessment Criteria Voldaan
|
||||
|
||||
- [x] **High Priority**: Nieuwe gebruikersgerichte functionaliteit (authenticatie, gebruikersbeheer)
|
||||
- [x] **High Priority**: Multi-persona systeem (Eigenaar, Beheerder, Gebruiker met verschillende rechten)
|
||||
- [x] **High Priority**: Customer-facing API (klanten gebruiken deze API voor websites/applicaties)
|
||||
- [x] **High Priority**: Complexe business logica (hiërarchische rollen, bevoegdheidsgrenzen)
|
||||
- [x] **Medium Priority**: Meerdere componenten en gebruikerstouchpoints
|
||||
- [x] **Medium Priority**: Hoge business impact en risico op misverstand bij rolhiërarchie
|
||||
|
||||
## Beslissing
|
||||
**User Stories uitvoeren**: Ja
|
||||
|
||||
**Redenering**: Het project heeft meerdere duidelijk onderscheiden gebruikerstypes met complexe, hiërarchische bevoegdheden. User stories zullen helpen om de exacte grenzen van elke rol te verduidelijken, acceptatiecriteria te definiëren voor de rolhiërarchie, en een gedeeld begrip te creëren van wat elke gebruiker wel en niet mag doen.
|
||||
|
||||
## Verwachte Uitkomsten
|
||||
- Duidelijke acceptatiecriteria per rol (Eigenaar, Beheerder, Gebruiker)
|
||||
- Concrete testspecificaties voor autorisatielogica
|
||||
- Helder overzicht van gebruikersworkflows (login, gebruikersbeheer, module-interactie)
|
||||
- Betere basis voor implementatie van de hiërarchische RBAC
|
||||
Reference in New Issue
Block a user