# Category 4: Data

> **Usage:** Definition of entities and data rules
> **When to load:** If feature is data-centric or full module

---

## 4.1 Entities

| # | Question | Answer Type |
|---|----------|-------------|
| Q4.1 | What are the main entities handled? | List |
| Q4.2 | For each entity: important attributes? | Per entity |
| Q4.3 | What relationships exist between entities? | Text schema |
| Q4.4 | Expected data volume? | Estimation |

## 4.2 Data Rules

| # | Question | Answer Type |
|---|----------|-------------|
| Q4.5 | What validations on data? | List of rules |
| Q4.6 | Which fields are required vs optional? | Per field |
| Q4.7 | What specific formats/constraints? | List |
| Q4.8 | Sensitive data to protect? | List + level |

---

## Technical Mapping

| Business Concept | Platform |
|-----------------|------------|
| Main entity | Domain Entity |
| Required attribute | `[Required]` |
| Unique attribute | `HasIndex().IsUnique()` |
| 1:N relationship | Navigation property |
| Sensitive data | Encryption + audit |

> **⚠️ RBAC EXCLUSION: The following concepts are handled by the platform's RBAC system
> and MUST NOT be modeled as entity attributes or separate entities:**
>
> | Concept | ❌ Wrong (entity attribute) | ✅ Correct (RBAC) |
> |---------|---------------------------|-------------------|
> | User role | `User.Role` property | Permission set `business.{app}.{module}.*` |
> | Access level | `User.AccessLevel` enum | Permission matrix per role |
> | Is admin | `User.IsAdmin` boolean | `business.{app}.{module}.admin` permission |
> | Can edit | `User.CanEdit` boolean | `business.{app}.{module}.update` permission |
>
> When Q4.2 asks for "important attributes", **exclude** any role/permission/access concept.

## Elicitation Guide

### Follow-ups by Question

| Question | If answer is vague/insufficient | Probe |
|----------|-------------------------------|-------|
| Q4.1 (entities) | Single entity listed | "Cette entité a-t-elle des sous-éléments ? (lignes de commande, pièces jointes, historique)" |
| Q4.1 (entities) | Mentions "User" as entity | "L'utilisateur est géré par la plateforme (Identity). Décrivez plutôt l'entité MÉTIER (Client, Employee, Contact...)" |
| Q4.2 (attributes) | Liste de champs techniques (ID, CreatedDate) | "Les champs techniques (Id, TenantId, audit) sont auto-gérés. Quels sont les attributs MÉTIER ?" |
| Q4.3 (relationships) | "1:N" without detail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
| Q4.4 (volume) | "Beaucoup" | "Ordre de grandeur : dizaines, centaines, milliers, millions ? Croissance par mois ?" |
| Q4.5 (validations) | Validations basiques seulement | "Y a-t-il des règles inter-champs ? (date fin > date début, montant selon statut)" |
| Q4.8 (sensitive) | "Non" | "Pas de données personnelles (nom, email, téléphone) ? Pas de données financières ?" |

### Anti-patterns to Detect

| Signal | Anti-pattern | Action |
|--------|-------------|--------|
| Entity "User" avec attributs métier | **Confusion User/Identity** | La plateforme gère les Users via Identity. L'entité métier = Client, Employee, Contact |
| Attributs Id, TenantId, CreatedBy listés | **Champs techniques comme métier** | Ces champs sont auto-générés par `AuditableEntity`. Ne pas les lister. |
| Pas de soft delete mentionné | **Suppression non clarifiée** | "Les données supprimées sont-elles effacées définitivement ou archivées ?" → `SoftDeletableEntity` |
| Aucune contrainte d'unicité | **Unicité non vérifiée** | "Deux entités peuvent-elles avoir le même nom/code/email ?" |

### Entity Patterns

| Besoin métier | Base class plateforme | Inclut automatiquement |
|---------------|----------------------|----------------------|
| Entité simple | `Entity` | Id, TenantId |
| Avec audit | `AuditableEntity` | + CreatedBy, CreatedDate, ModifiedBy, ModifiedDate |
| Avec suppression logique | `SoftDeletableEntity` | + IsDeleted, DeletedBy, DeletedDate |
| Avec hiérarchie | `HierarchicalEntity` | + ParentId, Level, Path |
