Mais pourquoi utiliser un DSL pour coder une séquence de traitements ordonnés et collaboratifs ?
Sur mon projet actuel, il y a un framework d'exécution de processus séquentiels ordonnés collaboratifs (j'essaye de trouver un nom !!).
C'est vrai qu'ici, pour traiter un cas d'utilisation donné, il faut "respecter" ("ah, DSL !" (*)) une "séquence" dans les traitements macros. Un traitement macro est macro au sens où il peut comporter une algorithmique importante, orchestrer des sous traitements eux unitaires. Mais chaque traitement macro ne peut se faire que dans un certain ordre avant / après les autres, et d'ailleurs les données requises par certains sont logiquement fournies par des traitements qui les précèdent.
Ah je dois vous dire: il y a du système central à requêter par derrière, et c'est bien lui qui "impose" ces "règles" d'exécution séquentialisées, ordonnées et collaboratives. Contraindre la séquence, ne fournir les données qu'au dernier moment, est un moyen efficace, euh un moyen quoi, d'imposer des règles de gestion dans un système central.
Sur mon projet, on conçoit des services dont le coeur est géré par le système central. Un jour, des concepteurs ont pensé qu'un DSL permettrait d'aider les développements à rentrer dans cette logique imposée par le système externe. Le langage a été pondu sous forme de grammaire XML, le moteur a été aisé à construire en Java, c'est une démarche très habituelle, peu couteuse. Le développeur implémente en XML une "séquence ordonnée" faisant apparaitre des étapes avec entrées et sorties sous forme de classes java. La séquence répartit les données à chaque étape en fonction de ses besoins, données qu'elle gère en global à son niveau.
Notez bien que le DSL n'est pas orienté "moteur de règle" au sens où on ne ferait que déclarer des traitements macros et leurs dépendances, et le moteur déduirait la séquence et les données à transférer : c'est inutile ! Ici le besoin est plus de maintenabilité, de clarté du code, et de non introduction de caca. Ce n'est que de l'informatique de gestion... :-))
Mon travail dans les jours /semaines à venir, ça va être de me dire : 1) est ce qu'on a bien tout vu dans le contrat, y'a par ex trop de spaghetti dans la façon de gérer les données 2) est ce qu'on n'a pas une solus basée java en alternative à la DSL XML qui en terme de code helper / compilateur / debuggeur nous transforme en d'Aboville du code (on y arrive, mais qu'est ce qu'on en chie)
(*) Paf ! - Une baffe, oui.
C'est vrai qu'ici, pour traiter un cas d'utilisation donné, il faut "respecter" ("ah, DSL !" (*)) une "séquence" dans les traitements macros. Un traitement macro est macro au sens où il peut comporter une algorithmique importante, orchestrer des sous traitements eux unitaires. Mais chaque traitement macro ne peut se faire que dans un certain ordre avant / après les autres, et d'ailleurs les données requises par certains sont logiquement fournies par des traitements qui les précèdent.
Ah je dois vous dire: il y a du système central à requêter par derrière, et c'est bien lui qui "impose" ces "règles" d'exécution séquentialisées, ordonnées et collaboratives. Contraindre la séquence, ne fournir les données qu'au dernier moment, est un moyen efficace, euh un moyen quoi, d'imposer des règles de gestion dans un système central.
Sur mon projet, on conçoit des services dont le coeur est géré par le système central. Un jour, des concepteurs ont pensé qu'un DSL permettrait d'aider les développements à rentrer dans cette logique imposée par le système externe. Le langage a été pondu sous forme de grammaire XML, le moteur a été aisé à construire en Java, c'est une démarche très habituelle, peu couteuse. Le développeur implémente en XML une "séquence ordonnée" faisant apparaitre des étapes avec entrées et sorties sous forme de classes java. La séquence répartit les données à chaque étape en fonction de ses besoins, données qu'elle gère en global à son niveau.
Notez bien que le DSL n'est pas orienté "moteur de règle" au sens où on ne ferait que déclarer des traitements macros et leurs dépendances, et le moteur déduirait la séquence et les données à transférer : c'est inutile ! Ici le besoin est plus de maintenabilité, de clarté du code, et de non introduction de caca. Ce n'est que de l'informatique de gestion... :-))
Mon travail dans les jours /semaines à venir, ça va être de me dire : 1) est ce qu'on a bien tout vu dans le contrat, y'a par ex trop de spaghetti dans la façon de gérer les données 2) est ce qu'on n'a pas une solus basée java en alternative à la DSL XML qui en terme de code helper / compilateur / debuggeur nous transforme en d'Aboville du code (on y arrive, mais qu'est ce qu'on en chie)
(*) Paf ! - Une baffe, oui.
Commentaires