Justification de l’architecture

Décisions d’Architecture – Composant Lambique

Ce document formalise certaines décisions d’architecture concernant le composant Lambique et son extension LambiqueGlobal, en mettant l’accent sur des choix pragmatiques qui s’éloignent volontairement d’une architecture strictement découplée.

📌 Contexte

Le projet repose sur un socle technique appelé Lambique, utilisé dans tous les modules métier. Il fournit des services transverses (UI, base de données, conversions, etc.) ainsi que certaines listes métier courantes (ex. : UtilisateurListe, DeviseListe, etc.).

🔄 Problème initial

L’intégration directe des listes métier dans Lambique peut provoquer la création multiple de ces listes par différents modules, ce qui mène à une duplication d’état, des performances dégradées et une incohérence potentielle.

✅ Solution retenue

Conserver les classes des listes métier (ex : UtilisateurListe) dans le composant Lambique.
Injecter dynamiquement les instances dans LambiqueGlobal au démarrage de l’application via SetListe().
Utiliser des objets dynamiques pour limiter le couplage, tout en permettant le cast explicite pour bénéficier de l’auto-complétion.

🎯 Justification de l’entorse à une architecture « pure »

1. Centralisation du cycle de vie

En passant par LambiqueGlobal, les instances des listes sont uniques, évitant les redondances et assurant la cohérence des données.

2. Confort de développement (auto-complétion)

Les classes étant déclarées dans Lambique, intégré partout, on peut caster les objets dynamiques issus de LambiqueGlobal pour récupérer le type réel :

MaListeUtilisateur est un UtilisateurListe = GUtilisateur

Cela permet d’avoir l’auto-complétion et l’accès aux méthodes spécifiques de la classe.

3. Stabilité fonctionnelle des entités

Il est peu probable que les objets comme les utilisateurs, devises ou langues nécessitent plusieurs implémentations. Il n’est donc pas nécessaire, à ce stade, de généraliser via des interfaces ou composants séparés.

Note : En cas d’évolution future (SSO, externalisation métier, tests poussés), cette architecture reste adaptable via l’injection dynamique d’alternatives implémentant les interfaces existantes.

🧠 Bilan

Cette approche maintient un bon équilibre entre :

Lisibilité et maintenabilité du code
Centralisation des instances métier
Facilité de développement (auto-complétion, pas de composants multiples)
Ouverture à une future montée en abstraction, si nécessaire

Elle constitue donc une entorse assumée et documentée à une architecture « parfaite », en faveur d’un pragmatisme efficace.