# Categorie 5 : Impact cross-module

> **Usage :** Analyser l'impact sur les modules existants et les dependances partagees
> **Quand charger :** TOUJOURS pour les nouveaux modules (pas les ameliorations)
> **Objectif :** Detecter les interactions, les entites partagees et les risques de conflit

---

## 5.1 Dependances avec les modules existants

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q5.1 | Avec quels modules existants ce nouveau module interagit-il ? | Liste de modules |
| Q5.2 | Quelles donnees sont partagees entre modules ? (entites, tables de reference) | Par module |
| Q5.3 | Y a-t-il des entites existantes que ce module va referencer ? (relations FK) | Liste de references |
| Q5.4 | Ce module produira-t-il des evenements que d'autres modules consomment ? | Liste d'evenements |

## 5.2 Evaluation d'impact

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q5.5 | Les modules existants doivent-ils etre modifies pour supporter ce nouveau module ? | Liste de changements |
| Q5.6 | Y a-t-il des composants UI ou des changements de navigation partages ? | Liste |
| Q5.7 | Ce module affectera-t-il les permissions ou roles existants ? | Oui/Non + detail |
| Q5.8 | Y a-t-il un risque de conflit de modele de donnees ? (meme entite modifiee par 2 modules) | Evaluation du risque |

---

## Cross-Module Patterns

| Besoin | Pattern | Exemple |
|--------|---------|---------|
| Reference une entite | Navigation property + FK | `Order.ClientId -> Client` |
| Donnees de reference partagees | Entite partagee dans Domain | `Status`, `Category` |
| Notification evenementielle | MediatR notification | `OrderCreatedNotification` |
| Requete cross-module | DTO en lecture seule | `IClientQueryService` |
| Lien de navigation | NavRoute entry | `business/{app}/{module}` |
| Permission partagee | Hierarchie de permissions | `{app}.*` covers all modules |

---

## Guide d'elicitation

### Techniques de relance

| Question | Si la reponse est vague | Relance recommandee |
|----------|------------------------|---------------------|
| Q5.1 (interactions) | "Aucun" | "Ce module est totalement isole ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
| Q5.2 (donnees partagees) | "Je ne sais pas" | Utiliser le `{codebase_context}` : "J'ai trouve les entites {list}. Ce module a-t-il besoin de les referencer ?" |
| Q5.3 (FK references) | Vague | "Une {entity} de ce module appartient-elle a un {existing_entity} ?" |
| Q5.4 (evenements) | "Non" | "Quand un {entity} est cree/modifie/supprime, faut-il notifier un autre module ?" |
| Q5.8 (conflits) | "Pas de risque" | "Deux modules modifient-ils la meme entite ?" |

### Anti-patterns a detecter

| Signal | Anti-pattern | Action |
|--------|-------------|--------|
| Module totalement isole | Silo de donnees | Rare qu'un module metier n'ait aucune connexion. Verifier avec le codebase context. |
| Duplication d'entite existante | Entite dupliquee | Si `Client` existe deja, ne pas creer `Customer`. Referencer l'existant. |
| Modification d'entite d'un autre module | Couplage fort | Utiliser des evenements (MediatR) plutot que des modifications directes. |

---

## Mapping vers la consolidation

| Reponse | Alimente |
|---------|----------|
| Q5.1-Q5.4 | `consolidation.crossModuleInteractions[]`, `consolidation.sharedEntities[]` |
| Q5.5-Q5.8 | `consolidation.globalRiskAssessment[]`, `consolidation.permissionCoherence` |
