# 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 |
| Q4.4b | For each entity: should the Code be auto-generated or user-provided? | Per entity |
| Q4.4c | If auto-generated: what strategy? (sequential, daily timestamp, yearly, UUID short) | Per entity |
| Q4.4d | What prefix represents this entity? (2-6 lowercase letters, e.g., emp, inv) | Per entity |

## 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 |
| Code auto-generation | `ICodeGenerator<T>.NextCodeAsync()` with retry — see `apex/references/code-generation.md` |
| Code pattern config | `analysis.entities[].codePattern` in feature.json |

> **⚠️ 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.4b (code pattern) | "User enters the code" or no answer | "Le code doit-il suivre un format spécifique ? (numéro séquentiel, date, combinaison ?)" |
| Q4.4c (code strategy) | No answer | Propose strategy based on entity type: invoices/orders → timestamp-daily, employees/customers → sequential, references/categories → uuid-short, contracts → year-sequential, tickets → timestamp-minute |
| Q4.4d (code prefix) | Too long or ambiguous | "Le préfixe est limité à 2-6 lettres minuscules. Exemple : 'emp' pour Employee, 'inv' pour Invoice, 'ctr' pour Contract." |
| 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 |
