Comment décider entre étendre le monolithe ou découper en services?
#1
Salut tout le monde. Je suis en train de refactoriser un vieux module de traitement de données et je me retrouve coincé sur un choix d’architecture : est-ce que je continue à étendre la classe monolithique principale avec des méthodes utilitaires, ou est-ce que je la découpe en plusieurs services plus spécialisés ? J’ai l’impression que la deuxième option serait plus propre à long terme, mais ça implique de toucher à pas mal d’appels existants et j’hésite à me lancer là-dedans. Je me demande si quelqu’un a déjà été dans cette situation de refactoring progressif sans tout casser.
Répondre
#2
Pour la refactorisation je vois trois axes possibles. Le premier consiste a rester sur le monolithe et a ajouter des utilitaires sans changer les appels existants. Le second consiste a decouper le monolithe en services specialisés ce qui clarifie les responsabilités mais peut casser les appels et demande des couches d abstraction et des contrats d interface. Le troisieme axe est une approche hybride avec une facade ou des adaptateurs et une migration progressive. Le choix doit aussi se baser sur la vitesse de livraison et sur les tests. Dans tous les cas la refactorisation doit se faire avec des tests de regression et un plan de migration.
Répondre
#3
Je avoue que je me mefie des gros refactors qui cassent les appels en cours et qui font perdre des semaines. Dans la refactorisation je partirais par petits pas et j ajouterais une couche d abstraction autour des structures actuelles pour tester l idee. On peut aussi mettre un feature flag pour activer la nouvelle voie et garder l ancien chemin pendant une periode. Le risque serait de se retrouver avec deux couches a maintenir et de compliquer le tracing ce pourquoi autant avancer prudemment. C est frustrant mais c est comme ca.
Répondre
#4
Personnellement dans ce type de refactorisation j ai eu envie de tout casser d un seul coup mais j ai appris a faire plus doucement. J ai commencé par extérioriser les parties sensibles en composants plus petits et j ai gardé le reste en place. Les tests et les retours des utilisateurs ont été mes amarrages. Pour moi le mot clé reste la clarté des interfaces et la tolérance a l erreur.
Répondre
#5
Et si le vrai enjeu n est pas d opposer monolithe et services mais de clarifier les interfaces et les contrats autour de la refactorisation. Cela passe par definir des ports et des adaptateurs et par accepter qu on migre petit a petit sans tout casser. Cela vous parle ?
Répondre


[-]
Réponse rapide
Message
Saisissez votre réponse à ce message ici.

Code de confirmation
Veuillez saisir le texte figurant dans l’image ci-dessous. Ce procédé permet de bloquer les robots.
Code de confirmation
(insensible à la casse)

Aller au forum