Menu de la documentation

Concept technique d’OwlMeans

Sur cette page

Une application OwlMeans suit une structure cohérente dès sa première version. Cette structure donne une place bien définie aux nouvelles fonctionnalités et fournit aux agents de programmation une manière commune de comprendre le projet.

Comment les éléments s’articulent

flowchart TD
    A[User interface and forms] --> B[Application behavior]
    B --> C[Authorization and services]
    C --> D[Database and shared state]
    E[Configuration and project guidance] --> A
    E --> B
    E --> C

L’interface recueille les données saisies et présente les résultats. Le comportement de l’application décrit ce que fait le produit. Les services exécutent les opérations réutilisables et vérifient les autorisations. La base de données conserve les enregistrements. La configuration partagée et les consignes destinées aux agents assurent la cohérence entre ces éléments.

Des définitions partagées pour des modifications cohérentes

Les applications générées utilisent des définitions partagées pour les requêtes, les réponses et les règles d’accès. L’interface et l’API s’appuient sur le même contrat, ce qui permet de garder les champs et les permissions d’une fonctionnalité cohérents. OwlMeans Common fournit des modèles réutilisables pour ces définitions et les services qui les mettent en œuvre.

La configuration fournit à l’application une méthode uniforme pour trouver les services. Le cadre d’exécution des agents (harness) décrit ces conventions : un nouvel agent peut ainsi étendre la structure existante sans reconstruire les fondations.

Les avantages de cette structure

  • Des modifications cohérentes : un nouvel écran suit les mêmes conventions de formulaires, de services et d’accès que les écrans précédents.
  • Des permissions claires : l’identité et les autorisations font partie des fondations de l’application, ce qui permet aux règles d’accès de suivre le comportement métier.
  • Des composants réutilisables : OwlMeans Common fournit une grande partie du code partagé de l’application. Vous pouvez consacrer davantage de temps à définir les comportements dont les utilisateurs ont besoin.
  • Une continuité entre agents : des compétences adaptées et la mémoire du projet expliquent les conventions à un agent qui intervient plus tard.
  • Une structure qui peut évoluer : séparer les responsabilités facilite l’extension de l’application lorsque de nouveaux besoins apparaissent.

Les conventions de projet create-app et les packages publics OwlMeans Common constituent la base de cette approche. Les pages consacrées aux technologies expliquent le rôle des bibliothèques utilisées.

Mettre cette approche en pratique

  1. Décrivez le résultat métier et les rôles des utilisateurs dans la spécification.
  2. Limitez chaque user story à un comportement que vous pouvez démontrer.
  3. Demandez à l’agent de respecter l’architecture existante du projet lorsqu’il ajoute une fonctionnalité.
  4. Vérifiez ensemble l’écran, les enregistrements stockés et les permissions.
  5. Conservez le cadre d’exécution et la mémoire lorsque vous confiez le développement à un autre agent.

Pour un CRM, cela signifie que le formulaire de contact, le service de contacts et les règles de visibilité partagent une même définition des personnes autorisées à lire et à modifier une fiche client.

Exemple d’application

Catégorie : CRM et gestion de la clientèle. Exemple : un CRM pour une petite équipe, avec attribution des contacts et accès pour les responsables.