Dans le cas où l’on travaille sur une application « monolithique », il peut être compliqué de conserver une productivité importante du fait de la complexité inhérente à l’application et aux différentes contraintes qui ont pu s’accumuler avec le temps. Par ailleurs, les outils de développement et mêmes les architectures applicatives employées peuvent devenir obsolètes. On commence dès lors à rencontrer des difficultés pour maintenir cette application.
Remplacer complètement un système existant peut vite devenir une tâche titanesque. Bien souvent, on va avoir besoin d’une méthode de migration partielle. On va alors faire cohabiter temporairement l’ancien système avec un nouveau qui pourra par exemple utiliser l’architecture microservice, bien plus moderne.
Cependant, faire fonctionner en parallèle deux « versions » d’une application va nécessiter la mise en place d’une stratégie que l’on inclue dans le pattern de programmation dit du « Strangler Pattern ». Il propose la mise en place d’une brique en façade qui va permettre d’effectuer une bascule transparente entre l’ancien et le nouveau système.
Figure 13 – Transition d’un système legacy vers un système moderne
Comme indiqué dans le retour du pattern « Choregraphy », il nous a été demandé de mettre en place une gateway d’interopérabilité pour le protocole Interop‘Fibre. Cette dernière venait en remplacement d’une application monolithique devenue trop dure à maintenir. Il est important de noter que le protocole Interop’Fibre repose sur l’échange de fichiers CSV à l’aide d’instance SFTP. Ce mécanisme s’avère être une chance, car nous tenons une « façade » déjà en place. Pour rappel, la façade permet de masquer et d’effectuer une transaction douce entre l’application existante et la nouvelle. Dans la mesure où le protocole Interop possède des sous-ensembles correspondant à des répertoires sur les instances SFTP, il est facile de faire la bascule en changeant progressivement la responsabilité des répertoires de l’ancienne application vers la nouvelle. Il nous a été possible de répartir les développements dans le temps en procédant répertoire par répertoire avant que les utilisateurs n’aient pas à subir la migration progressive des services.