# Category 13: Cross-Module Impact

> **Usage:** Analyze impact on existing modules and shared dependencies
> **When to load:** ALWAYS for new modules (not enhancements)

---

## 13.1 Existing Module Dependencies

| # | Question | Answer Type |
|---|----------|-------------|
| Q13.1 | Which existing modules does this new module interact with? | List |
| Q13.2 | What data is shared between modules? (entities, lookup tables) | Per module |
| Q13.3 | Are there existing entities this module will reference? (FK relationships) | List |
| Q13.4 | Will this module produce events that other modules consume? | List of events |

## 13.2 Impact Assessment

| # | Question | Answer Type |
|---|----------|-------------|
| Q13.5 | Will existing modules need modifications to support this new module? | List of changes |
| Q13.6 | Are there shared UI components or navigation changes? | List |
| Q13.7 | Will this module affect existing permissions/roles? | Yes/No + detail |
| Q13.8 | Is there a risk of data model conflicts? (same entity modified by 2 modules) | Risk assessment |

---

## Cross-Module Patterns

| Need | Pattern | Example |
|------|---------|---------|
| Reference another entity | Navigation property + FK | `Order.ClientId → Client` |
| Shared lookup data | Shared entity in Domain | `Status`, `Category` entities |
| Event notification | MediatR notification | `OrderCreatedNotification` |
| Cross-module query | Read-only DTO from other module | `IClientQueryService` |
| Navigation link | Menu entry in NavRoute | `business/{app}/{module}` |
| Shared permission | Permission hierarchy | `business.{app}.*` covers all modules |

## Elicitation Guide

### Follow-ups by Question

| Question | If answer is vague/insufficient | Probe |
|----------|-------------------------------|-------|
| Q13.1 (interactions) | "Aucun" | "Ce module est totalement isolé ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
| Q13.2 (shared data) | "Je ne sais pas" | Use `{codebase_context}` from pre-research: "J'ai trouvé les entités {list} dans {app}. Ce module a-t-il besoin de les référencer ?" |
| Q13.3 (FK references) | Vague | "Une {entity} de ce module appartient-elle à un {existing_entity} ? (ex: OrderLine → Product)" |
| Q13.4 (events) | "Non" | "Quand un {entity} est créé/modifié/supprimé, faut-il notifier un autre module ? Mettre à jour un compteur ?" |
| Q13.5 (modifications) | "Non" | "Pas de nouvelle colonne dans le menu ? Pas de lien depuis une page existante vers ce nouveau module ?" |
| Q13.8 (conflicts) | "Pas de risque" | "Deux modules modifient-ils la même entité ? (ex: module A crée un Client, module B le modifie)" |

### Anti-patterns to Detect

| Signal | Anti-pattern | Action |
|--------|-------------|--------|
| Module totalement isolé | **Silo de données** | Rare qu'un module métier n'ait aucune connexion. Vérifier avec le codebase context. |
| Duplication d'entité existante | **Entité dupliquée** | Si `Client` existe déjà, ne pas créer `Customer`. Référencer l'existant. |
| Modification d'entité d'un autre module | **Couplage fort** | Utiliser des événements (MediatR) plutôt que des modifications directes. |
| Aucune mention de navigation | **Module orphelin dans l'UI** | Le module doit apparaître dans le menu de l'application (NavRoute). |

### Using Pre-Research Context

> **IMPORTANT:** This category benefits most from step 3 (Pre-Research).
>
> Use `{codebase_context}` to:
> - **List existing entities** and ask the user which ones this module references
> - **Show existing modules** and ask about interactions
> - **Detect potential duplicates** (entity names similar to what the user describes)
> - **Propose event patterns** based on existing MediatR notifications
