83 lines
4.2 KiB
Markdown
83 lines
4.2 KiB
Markdown
# 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).
|