Omika/docs/audit-niveau-3.md

Audit du niveau 3 — Modèle métier canonique et contrats API

Types déjà trouvés dans Omika.Core

L'audit a couvert les dossiers existants et les dossiers créés :

• Omika.Core/Abstractions : abstractions techniques existantes.
• Omika.Core/Constants : constantes existantes.
• Omika.Core/Interfaces : interfaces existantes.
• Omika.Core/Models : modèles préexistants (à auditer pour doublons éventuels).
• Omika.Core/Runtime : contexte d'exécution (ex. ApplicationRuntimeContext), sélection de base demandée par la configuration (DatabaseSchemaSelection) et analyse de configuration (DatabaseSchemaSelectionParser).
• Omika.Core/Compatibility (créé) : DatabaseSchemaVersion (provenance / version réellement détectée), DatabaseSource, LegacyEntityReference, SchemaCapabilities, CanonicalMappingResult<T>.
• Omika.Core/Domain (créé) : entités métier, objets de valeur, enums, exceptions.
• Omika.Core/Contracts (créé) : DTO API.
• Omika.Core/Mapping (créé) : mappers entité métier → DTO.

Types réutilisés

Aucun fichier existant n'a été déplacé. Les dossiers Interfaces, Abstractions, Constants et Runtime ont été réutilisés tels quels : la nouvelle structure Domain/, Contracts/, Compatibility/ est ajoutée sans déplacer les classes existantes.

La règle « ne crée pas un deuxième dossier concurrent » a été respectée : les nouvelles interfaces de service ont été placées dans Omika.Core/Interfaces et non dans un nouveau dossier.

Doublons évités

• Un seul RendezVous canonique (pas de Planning_RDV / RDV_Planning / RDV_Collaborateur / RDV_Contact métier).
• Un seul Document (pas de duplication des classes physiques DocumentRow).
• Un seul Client (pas de duplication des tables Client, ClientAdresse, ClientContact, ClientSite).
• Un seul Intervention (pas de duplication des tables Intervention, ActionIntervention, CompteRendu).
• Les collections métier (adresses, contacts, sites) sont des propriétés de l'entité racine, et non des entités séparées dupliquées.
• Pas de table de liaison métier : les références sont portées par des listes d'identifiants ou des collections contrôlées.

Fichiers non déplacés

• Les classes physiques Batik / Omika restent dans Omika.Data.
• Les classes de Omika.Core/Models existantes n'ont pas été déplacées par sécurité : un audit manuel complémentaire est nécessaire pour décider de leur sort (doublons éventuels avec Domain/).
• Les abstractions techniques de Abstractions/, les constantes de Constants/ et le runtime de Runtime/ restent en place.

Ambiguïtés

1. Omika.Core/Models : contient peut-être des DTO ou modèles intermédiaires préexistants. Rien n'a été supprimé ; à arbitrer lors du niveau 4.
2. Interfaces de repository : la solution ne montre pas de convention claire de repository. Les services (IClientService, IInterventionService, IRendezVousService, IDocumentService, IReferenceDataService, ICurrentUserService) ont été créés dans Interfaces/. Les repositories seront définis avec l'architecture de données (Omika.Data).
3. Identifiants publics : chaînes. Le mobile ne doit pas voir la clé physique ; un helper dédié sera ajouté si nécessaire.
4. ReferenceValue vs enums : les paramètres métier restent configurables. Certains statuts pourraient devenir des enums stables ultérieurement.
5. Dates : DateTime partout ; DateTimeOffset seulement si un besoin multi-fuseaux est documenté.

Éléments restant à traiter

• Mapping physique → métier dans Omika.Data (Batik et Omika) : conversion des rubriques préfixées et des champs zombie vers les entités canoniques de Omika.Core.Domain.
• Implémentation des services métier (IClientService, etc.) côté API.
• Décision sur le devenir de Omika.Core/Models (fusion ou suppression).
• Contrats de mise à jour des collections (remplacement complet vs diff).
• Sécurité : hachage des mots de passe, sessions, jetons (hors périmètre niveau 3).
• Gestion physique des documents (téléversement / téléchargement).