Architecture logicielle : Les parties difficiles

Chapitre 4. Décomposition architecturale

Cet ouvrage a été traduit à l'aide de l'IA. Tes réactions et tes commentaires sont les bienvenus : [e-mail]

Monday, October 4, 10:04

Maintenant qu'Addison et Austen avaient le feu vert pour passer à une architecture distribuée et briser l'application monolithique Sysops Squad, ils devaient déterminer la meilleure approche pour savoir comment commencer.

"L'application est tellement grande que je ne sais même pas par où commencer. Elle est aussi grosse qu'un éléphant !" s'exclame Addison.

"Eh bien", dit Austen. "Comment mange-t-on un éléphant ?"

"Ha, j'ai déjà entendu cette blague, Austen. Une bouchée à la fois, bien sûr !", dit Addison en riant.

"Exactement. Alors utilisons le même principe avec l'application de l'escouade Sysops", dit Austen. "Pourquoi ne pas commencer à la décomposer, une bouchée à la fois ? Tu te souviens que j'ai dit que les rapports étaient l'une des causes du blocage de l'application ? Peut-être devrions-nous commencer par là."

"C'est peut-être un bon début", a déclaré Addison, "mais qu'en est-il des données ? Faire des rapports un service distinct ne résout pas le problème. Nous devrions également séparer les données, ou même créer une base de données de rapports séparée avec des pompes à données pour l'alimenter. Je pense que c'est une trop grosse bouchée à prendre dès le départ."

"Tu as raison", dit Austen. "Hé, qu'en est-il de la fonctionnalité de la base de connaissances ? Elle est assez ...