Le Transaction Script est un patron de conception (résous des problèmes récurrents de conception). Il organise la logique métier d’une application backend grâce à des procédures uniques, et chaque procédure répond entièrement à une demande. Par exemple, dans un système bancaire, il y a la consultation d’un compte, le virement d’argent, ou la souscription à une offre.
Ce patron de conception est utilisé dans le modèle client-serveur. Le serveur effectue plusieurs transactions avec la base de données, mais aussi des vérifications ou des calculs. Avec le Transaction Script, on regroupe cette logique à un seul endroit, dans une procédure. La couche présentation n’appelle qu’une seule procédure par requête.
Simpliste, il n’a pas de couche de persistance. Donc pas d’ORM, sinon ça peut ressembler à la conception anémique qui est un anti-pattern (mauvaise conception). Les appels à la base de données se font directement dans la procédure, et peuvent être accompagnés d’une petite librairie d’accès à la base de données, comme JDBI en Java. À noter que ce modèle influence l’architecture.
Dans le code source, les Transaction Script sont souvent regroupés par sujet. Si je reprends l’exemple de la banque, le virement d’argent a d’autres transactions autour de lui : l’ajout de bénéficiaire, le suivi des virements, ou la consultation du plafond de virement. En programmation orientée objet, on pourrait avoir une même classe qui regroupe plusieurs fonctions. Rassembler pourrait ne pas convenir si des états sont conservés dans la classe pendant les transactions.
Facile à mettre en œuvre, le Transaction Script convient à une logique métier qui n’est pas trop complexe, à l’instar d’une petite application web. Ça peut être le cas des microservices, car les applications sont plus petites. Il a toutes ces chances d’être un choix face au grand Domain Model, le lourd patron de conception.
