Architecture logicielle : Les parties difficiles

Chapitre 11. Gestion des flux de travail distribués

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

Tuesday, February 15, 14:34

Austen s'est précipité dans le bureau de Logan juste après le déjeuner. "J'ai regardé les nouvelles conceptions architecturales, et je veux aider. Tu as besoin de moi pour rédiger quelques ADR ou pour t'aider avec quelques pointes ? Je serais ravi de rédiger l'EIM qui stipule que nous n'utiliserons que la chorégraphie dans la nouvelle architecture pour que les choses restent découplées."

"Holà, là, espèce de maniaque", dit Logan. "Où as-tu entendu cela ? Qu'est-ce qui te donne cette impression ?"

"Eh bien, j'ai beaucoup lu sur les microservices, et le conseil de tout le monde semble être de garder les choses fortement découplées. Quand je regarde les modèles de communication, il semble que la chorégraphie soit la plus découplée, donc nous devrions toujours l'utiliser, n'est-ce pas ?"

"Toujours" est un terme délicat dans l'architecture logicielle. J'avais un mentor qui avait un point de vue mémorable à ce sujet, qui disait toujours : Ne jamais utiliser d'absolus quand on parle d'architecture, sauf quand on parle d'absolus. En d'autres termes, ne jamais dire jamais. Je ne vois pas beaucoup de décisions en architecture où le toujours ou le jamais s'applique."

"D'accord", répond Austen. "Alors comment les architectes décident-ils entre les différents modèles de communication ...