Certaines classes de solutions tendent à dépendre de manière importante de l'utilisation de règles métier pour
extraire la variabilité de la solution et l'externaliser de façon à ce que les règles puissent évoluer indépendamment
de la logique applicative principale. En partant d'un modèle d'analyse métier comportant des entités métier et des
règles métier, il est possible de définir des services qui encapsulent les règles métier, en les externalisant par
rapport au reste de la logique de la solution. Le diagramme ci-dessous représente un exemple de modèle d'analyse métier
de taille réduite ; deux règles métier sont attachées à l'entité métier appelée Commande. Ces règles, étant attachées à
une entité métier, correspondent très probablement à des invariants de l'entité et seront donc évaluées à chaque
changement d'état de l'entité. Des règles peuvent également être attachées à des actions ou à des processus et sont
souvent évaluées en tant que préconditions ou postconditions de l'action.
Dans la modélisation de l'exemple ci-dessus, on suppose qu'il existe une relation traçable entre les spécifications de
service dérivées des travailleurs métier et le(s) message(s) dérivé(s) de l'entité métier.
Dans de nombreux cas, des règles complexes sont agrégées en jeux de règles, qui conviennent beaucoup mieux en termes de
granularité de service et permettent par exemple de transmettre un document au service de validation dans lequel le jeu
de règles est évalué et où les résultats sont renvoyés. En étudiant l'exemple ci-dessus, on peut aisément imaginer que
les services de validation sont en fait constitués d'un jeu de règles assez complexe permettant de valider la
compatibilité des éléments commandés, les quantités, etc.
|