Comment organiser son projet Mendix ?

J’entends par projet, la manière dont l’application en final va s’articuler au niveau de ses modules et de la décomposition des modules eux-mêmes, à l’aide de répertoires. Avant même de présenter les alternatives, je vois déjà la confrontation qui règne dans nos rangs.

On peut faire preuve d’une imagination sans limites – et être passablement “bordélique” – mais au final, il y a deux grandes écoles de pensées. Certains choisissent d’organiser leurs applications autour de ses besoins d’affaires (processus ou fonctionnalités) alors que d’autres vont l’organiser en se concentrant autour des structures de données. Je vous invite alors à regarder d’un peu plus prêt les avantages et les inconvénients de chaque solution.

Par besoins d’affaires

Une organisation par besoins d’affaires va permettre un regroupement des fonctionnalités qui va être très proche de l’interface graphique qui en découle. Ceci signifie que si le gestionnaire du produit consultait le Modeler (Studio Pro de Mendix), il pourrait facilement identifier la correspondance entre un processus et ce qu’il peut voir depuis son interface utilisateur (UI).

Pour l’intégrateur (personne qui transcrit le besoin fonctionnel en flux et composantes Mendix), cela va se traduire par une forte adhérence entre ce qu’il va produire et la compréhension du domaine d’affaires. Ceci est pour moi, l’aspect positif.

Le revers de la médaille est que nous allons avoir tendance à accroître les interdépendances entre les modules et donner une plus grande chance à la duplication de logiques. Ceci va d’autant être plus vrai si le travail est réparti entre différentes ressources pour traiter des processus d’affaires qui peuvent paraître différents, mais qui en fait suivent des logiques communes.

L’augmentation des interdépendances va décroître la maintenabilité du code (ceci peut être mis en valeur par un outil de mesure de la qualité du code comme Omnex). Une meilleure organisation devrait tendre à limiter les interdépendances entre modules pour en permettre leur réutilisation.

Par structure de données

Une organisation par structure de données, à l’opposé de la première solution, ne va pas être facilement accessible à un gestionnaire de produit. Mais, est-ce si important ? Pour ma part, ce qui est au niveau du ‘low-code’ ne devrait rendre confortable que l’intégrateur lui-même.

Le gestionnaire du produit valide son besoin d’affaires au travers de l’application en accédant à ses écrans. Le gros avantage est que nous allons pouvoir facilement isoler les traitements unitaires (Ajout, Modification, Suppression) sur les entités manipulées. Ceci va permettre de simplifier le processus de désolidarisation des modules qui composent l’application et certainement éviter la redondance de logique. L’objectif ultime est de séparer correctement les traitements en modules réutilisables. Une telle organisation va accroître la maintenabilité de l’application.

Maintenant que je me suis jeté dans l’arène, je serais curieux d’avoir vos commentaires : êtes vous “besoins d’affaires” ou “structure de données” ? Ou bien avez-vous une approche totalement différente ?

Nota Bene : ce sujet est abordé dans la documentation de Mendix. L’organisation par besoin d’affaires y est nommée Process-Related et celle par structure de données Entity-Related…

Ce billet fait partie d’une série d’articles en provenance du 🇨🇦 sur les bonnes pratiques Mendix et dédié uniquement aux francophones 😜.
Nous mettrons à jour la liste des billets de la série au fur et à mesure de leur publication.

• Organiser son projet
• À vos couleurs !
• Validation sans détour
• Comment va votre XPath ?