Quand utiliser les moteurs de workflow?
J'ai travaillé dans le passé sur certains des moteurs de workflow en tant que programmeur, mais je n'ai jamais su clairement pourquoi nous avions choisi les moteurs de workflow en premier lieu. Et en tant que programmeur, je sais qu'il y a au moins 100 façons de faire quoi que ce soit lorsque vous écrivez du code, mais seules quelques-unes sont les meilleures!
Je ne comprends toujours pas quels cas d'utilisation sont les mieux résolus par les moteurs de workflow (ou plutôt leur concept) plutôt que de concevoir une bonne application compatible DI. Je recherche des caractéristiques générales des cas d'utilisation neutres de domaine, où les moteurs de flux de travail sont l'une des meilleures options.
Ma question est donc la suivante: quelles sont les caractéristiques générales d'une exigence qui peuvent être considérées comme un signal pour opter pour un bon moteur de workflow et pour le coder?
Un moteur de workflow est utile lorsque vous devez passer du début à la fin, mais il existe de nombreux chemins/logiques/règles différents pour y parvenir.
Par exemple, disons que j'écris un programme qui publie du contenu. Donc, dans mon cas, la publication passe par un processus de révision, juridique, puis d'approbation finale. J'écris le programme implémentant ma logique de processus et mes étapes. Maintenant, cela fonctionne très bien pour moi et mon entreprise. Donc, je décide que d'autres devraient utiliser mon programme.
Malheureusement, tout le monde ne publie pas de contenu en utilisant le même processus, donc au lieu d'écrire des processus séparés pour chaque cas différent, nous implémenterions un processus de flux de travail afin que le programme soit flexible pour s'adapter à tout le monde. Peu importe le nombre d'étapes, de règles ou de logique entre ces deux points, le résultat est le même.
Donc, si vous avez des processus variables du début à la fin, utilisez un workflow. Si le même processus peut être utilisé par tout le monde, vous n'avez pas besoin d'un flux de travail.
Je sais que vous avez demandé des cas d'utilisation, mais il est plus facile d'énumérer les avantages que d'imaginer tous les cas d'utilisation possibles. Les avantages dépendent bien sûr du moteur et de la langue que vous comparez, mais en général:
Conserver les règles en tant que données au lieu de code signifie que vous n'avez pas à recompiler, vous pouvez donc tester les modifications rapidement, les modifier au moment de l'exécution, etc. Pas très avantageux si vous n'avez pas à recompiler en premier lieu, cependant.
On peut raisonnablement s'attendre à ce que les utilisateurs modifient les règles. Ils peuvent potentiellement bricoler avec eux de manière interactive, ce qui n'est pas possible lorsqu'ils demandent à un programmeur d'écrire du code pour eux.
Conserver les règles en tant que données permet d'écrire des outils pour visualiser et modifier les données.
Conserver les règles en tant que données permet la méta-programmation plus facilement - vous pouvez écrire du code pour analyser les données et en insérer plus de manière complexe, ce qui serait très difficile pour le code.
Toutes ces choses sont possibles directement avec du code (par exemple - écrire un analyseur C # pour trouver toutes les règles d'un certain type et générer du code pour plus de règles, l'insérer dynamiquement dans un assembly d'une manière qui permet le déchargement de l'assembly, écrire des outils pour les utilisateurs peuvent également le faire en utilisant votre visualiseur et votre éditeur) mais cela peut être beaucoup plus difficile en fonction de votre langue (les programmeurs utilisant un LISP peuvent appeler les éléments 1-4 "programmation").
À mon humble avis, le SEUL cas où vous devriez utiliser ce genre de chose, c'est quand il peut être configuré par des utilisateurs moins précieux. Si vous pouvez résoudre votre problème en leur donnant un outil, puis en recommençant à travailler sur autre chose plus important, utilisez-en un.
Si vous avez encore besoin de le configurer pour eux, j'imagine que vous pourriez penser à 10 façons différentes d'obtenir le même résultat avec un outil que vous connaissez et ce sera beaucoup plus facile à prendre en charge et à personnaliser.
Cela ressemble à une vieille question, mais revient souvent à l'état sauvage. Je suis d'accord avec réponse de Jon . J'ai trouvé que les moteurs de workflow étaient très productifs dans les scénarios suivants:
- Il existe un processus métier sous-jacent que vous essayez de représenter/mettre en œuvre via votre logiciel.
- Il existe une seule entité commerciale (peut-être composite) qui est travaillée à toutes ou à certaines étapes du processus. Dans l'exemple donné par Jon, cette entité ou cet élément de workflow serait du contenu ou un article. Considérez le suivi des bogues comme un autre exemple de flux de travail, un bogue transite entre différents états, en fonction d'une action qu'un utilisateur prend.
- Utilisez les workflows pour modéliser vos processus, uniquement si vous vous attendez à ce que le processus métier change, par changement, je veux dire la séquence ou l'action effectuée à la suite d'une action ou d'une transition utilisateur.
Soyez très prudent et critique pour voir si votre domaine/exigences de problème a un processus métier, n'essayez pas de "l'adapter" dans un flux de travail.
J'ai quelques directives que j'utilise pour suggérer des moteurs de flux de travail.
1) Lorsque les analystes commerciaux n'ont aucun fond de codage mais peuvent dessiner des diagrammes.
Les moteurs de flux de travail modernes utilisent la notation de modélisation des processus métier ou les versions moins performantes disponibles dans SharePoint et les systèmes similaires. Celles-ci permettent aux membres de l'équipe techniquement compétents mais ayant des difficultés de codage de concevoir et de développer de nombreux flux de travail.
2) Lorsque vous devez surveiller la progression du travail, effectuer des escalades, basculer entre les processus contrôlés par ordinateur et les processus contrôlés par l'homme.
La surveillance et l'auto-référence sont les caractéristiques des moteurs de flux de travail modernes.