Styles architecturaux protectionniste Flashcards
Expliquez le style architectural Client/Serveur.
Il est rare qu’une application vive de manière indépendante. Il y a souvent ce que l’on appelle des applications serveur (API/back-end/Database) et des applications clients (Application mobile, web, command line, application de bureau) qui doivent cohabiter dans l’écosystème de notre problème d’affaires. Nous n’allons tout de même pas demander à tout le monde de faire des appels d’API REST pour faire leurs actions. Ainsi, nous devons jumeler ces deux types d’applications dans notre architecture. Or, leur rapport de force peut justement apporter certaines complexités dans notre développement.
Quels sont les 3 types de collaboration dans un modèle Client/Serveur? Expliquez chacun de ces types avec un exemple.
- Thin client/ Thick server (client léger/ serveur puissant)
Dans ce type de collaboration, c’est le serveur qui est responsable de faire la majorité des règles d’affaires de notre système. Ainsi, notre application cliente n’est présente que pour l’affichage et l’interaction utilisateur, rien d’autre!
Dans l’exemple, le client ne serait responsable que d’afficher les informations du siège, le décompte pour faire la transaction et demander (formulaire) toutes les informations pour continuer le processus d’achat. C’est le serveur qui serait alors responsable de faire la logique de validation des infos de paiement, de créer la transaction (verrouillage) sur le siège et d’envoyer les communications.
- Thick client / Thin server (client puissant / Serveur léger)
Dans ce type de collaboration, le client a toute la puissance de la logique d’affaire. Il encapsule les règles d’affaires, l’affichage et l’interaction utilisateur. Il n’utilise le serveur que pour stocker des données et rien d’autre.
Dans l’exemple, le client serait responsable d’afficher les informations du siège, le décompte pour faire la transaction et demander (formulaire) en plus d’être celui qui initie la transaction, envoie la communication par courriel, et faire le paiment. Le serveur ne ferait que l’interface avec la Base de données du système.
- Thick client / Thick server (client puissant / serveur puissant)
Mode de fonctionnement couplé entre les deux parties qui ne savent pas vraiment qui doit posséder quel rôle. Nous allons avoir alors de la duplication de règles d’affaires dans les deux parties de notre système. Cela peut complexifier la conception du système.
Dans l’exemple, le client serait responsable d’afficher les informations du siège, le décompte pour faire la transaction et demander (formulaire) en plus d’être celui qui initie la transaction et valide les informations de paiement(carte de crédit valide). Cependant, le serveur pourrait être celui qui fait le paiement et envoie la communication par courriel pour conclure la transaction.
Expliquez qu’est-ce que le style orchestré.
Le mode par action/réaction domine notre manière de penser un système. Nous voulons faire quelque chose, alors appelons la bonne méthode, procédure , routes pour faire cet action. Ce type d’interaction est souvent vu comme étant un fonctionnement orchestré. Il y a un orchestrateur qui organise l’ordonnancement des actions à faire pour répondre à une action. La majorité des services applicatifs sont construits selon ce paradigme. Nous voyons souvent ce genre d’application dans tout ce qui gère une transaction et que nous voulons avoir une réponse totale à la fin du traitement.
Tous les appels seront alors chaînés pour permettre de faire étape par étape le développement de la solution. Cependant, il peut y avoir des limitations à ce mode de fonctionnement. Si nous avons plusieurs systèmes ou contextes différents qui demandent de faire un traitement, allons-nous les coupler tous ensembles? Si le traitement est long et fastidieux, est-ce que cela va donner une bonne expérience utilisateur? Ces limitations impacteront la conception orchestrée de nos applications.
Expliquez qu’est-ce que le style chorégraphié.
Le mode de fonctionnement évènementiel s’oppose au style orchestré en inversant le flux de contrôle. Nous ne voulons plus prendre la décision de qui doit faire x/y/z action. En fait, chacun des membres du système auront maintenant 2 buts dans leur vie utile, informer le monde extérieur qu’il vient de se passer un changement dans leur état interne et réagir à ces dit changement. On devient dans un mode où le modèle d’interaction s’attarde aux changements du passée. On réagit à ce qui vient de changer, au lieu de se faire dicter quoi faire. Ce mode de fonctionnement est lié aux styles architecturaux basés sur les évènements ou EBA.
Cependant, comme tout dans le système devient alors réactif, cela complexifie grandement la conception du logiciel. Il est plus difficile suivre l’évolution d’une action dans le système, car nous ne savons pas nécessairement qui intervient à quel instant. La force de ce genre de système réside dans leur découplage profond, chaque contexte augmente leur niveau d’indépendance entre les autres. On doit alors standardiser les évènements (qu’est-ce que j’informe aux autres, sur quoi dois-je réagir).
Expliquez le style Pub/Sub.
Le style publish subscribe est le premier style 100% évènementiel vu dans ce cours. Composante majeure d’une architecture EBA, il est responsable de mettre en communication les diverses composantes du système en implémentant un fonctionnement similaire à ce que le patron observateur présente, avec une touche de différence majeure, il généralise la gestion des évènements avec une gestion par type de messages (topics).
Quelles sont les 4 composantes d’une architecture Pub/Sub?
- Publisher / éditeur
L’éditeur est celui qui est responsable de lancer le message représentant l’évènement lorsqu’il se produit dans le processus. C’est la composante qui dit : “Voici ce qui vient de se passer dans mon contexte”. Il est responsable de donner tout le contexte nécessaire pour que les autres parties puissent réagir proprement à l’action qui vient de se passer.
- Subscriber / Abonné
L’abonné est celui qui va réagir à un évènement pour débuter un nouveau traitement. Il prend le message et doit alors faire les bons traitements. Il peut y avoir plusieurs abonnés qui pourraient être intéressés par l’évènement. Il faut donc concevoir le système en ayant cette information, car nous ne voulons pas créer plus de complexité à gérer le lancement de l’évènement. Il peut devenir un éditeur plus loin lorsque c’est nécessaire en fonction des changement sà son état ou à son parti de processus.
- Topic
Le topic est souvent lié à l’évènement qui est lancé, donc par exemple, si nous étions dans un système de gestion de billet de spectacle, lors de l’achat d’un billet par un client, nous allons avoir un évènement lancé comme suit: NouveauBilletAcheté. Cela représente un sujet qui pourrait intéresser plusieurs participants, comme le service d’envoie de courriel.
- Message broker
Technologie de gestion de message pour permettre le partage d’information, il peut y avoir plusieurs technologies utilisées pour permettre cela. Nous voyons souvent des services infonuagiques qui nous permettent de faire ces actions dans le système.
Quels sont les cas d’utilisation du Pub/Sub?
- Les styles d’application distribuée chorégraphiée
- Une application interne avec une queue de message pour éviter que les contextes ne se parlent entre eux
- Application de traitements différés
- Une application où les changements d’état vont être éventuellement consistants
Expliquez le CQRS.
Le CQRS (comand-query responsibility segregation) se veut un style architectural qui vient structurer une application en divisant les deux actions clés d’une application, la lecture et l’écriture. Nous allons changer la terminologie pour utiliser des termes orientés sur le domaine riche. On va ainsi dire qu’au lieu d’avoir une application où les objets sont entre-mêlés peut importe l’intention de l’utilisateur, nous allons créer une structure applicative où nous allons diviser l’intention entre visualisation et action. Donc, les objets que nous allons avoir pour lire l’état d’un contexte d’affaire ne seront pas les mêmes que ceux utilisés pour actionner dans le système. On va ainsi créer un division pour stabiliser l’évolution.
Exemple: - Cas d’utilisation: je veux acheter un billet d’un spectacle. L’objet pour spécifier la commande n’aura pas les même champs que ceux pour voir la commande. Si dans la commande d’achat, j’ajoute un code promo, celui ne pourrait ne pas se retrouver si je veux revoir la commande.
Nous allons alors nous retrouver avec deux modélisations, celle pour la “query” et celle pour la “commande” l’action.
Chacun des contextes de l’application a sa propre responsabilité, le côté Query ne fait que de la lecture sur la base de données, le côté commande est responsable d’effectuer les changements d’états dans l’objet.
Les interfaces d’interactions seront aussi divisées, car ce n’est pas tous les mêmes utilisateurs (persona) qui vont utiliser les deux sections de l’application.
Expliquez l’Event-Sourcing.
Ce style architectural vient apporter une nouvelle façon de gérer l’état dans un système. Normalement, nous gérons l’état d’un système en sauvegarde les données dès qu’il y a un changement dans un objet, un modèle ou une table de base de données. Cependant, dans certains cas d’utilisation, cela complexifie la situation, la gestion des données en temps réel dans le cas de multiples transactions sur un même objet peut s’avérer complexe, car il faut rajouter de la gestion de la concurrence. Ainsi, le style Event-sourcing vient apporter une manière de faire différente. Cela va différer selon les deux flux d’information, l’écriture et la lecture.
Écriture
Nous allons maintenant sauvegarder les changements d’états en fonction des évènements qui change le jeu de données,il n’y aura pas de changement directement de l’état, tout va se trouver dans les évènements. Nous aurons une structure pour reconstruire l’état de l’objet, comme un snapshot. Il y a donc deux parties dans l’écriture, la liste d’évènements depuis le dernier snapshot (image de l’état calculé) qui a été fait et aussi la gestion des snapshots. Nous allons avoir plusieurs types d’évènement en fonction des actions qui se déroulent dans le domaine.
Par exemple dans le diagramme précédent, nous pouvoir voir qu’il y a deux types d’évènements dans la gestion du flux de transport de bateau à un port. Nous voyons que les deux évènements qui héritent d’un évènement commun. C’est ce type de base qui sera persisté dans notre pile d’évènements.
Lecture
Le processus est plus complexe à gérer dans la lecture. La complexité vient de la gestion de la représentation de l’état qui doit être calculé en fonction du delta entre toute la liste d’évènement qui s’est accumule depuis le dernier snapshot. Ainsi, dans un cas de lecture de l’état du système, nous allons devoir traverser les évènements pour avoir la bonne représentation de l’état. Nous avons 3 mécanismes pour refaire l’état des objets:
- Reconstruction complète de l’état
Nous allons refaire l’objet en repartant de l’état de base et rejouer tous les évènements depuis le dernier état calculé pour avoir la vérité directe.
- Requête temporelle
Comme nous avons maintenant tous les changements sur l’état à travers le temps, ainsi nous pouvons retrouver l’état à un moment donné en utilisant un pointeur dans le temps. Donc on va choisir les évènements qui sont dans ce delta.
- Rejoué un évènement
Si un évènement a été mal appliqué, nous allons pouvoir justement corriger le tire et rajouter un évènement pour remettre l’état correct dans le système. Si cela doit se faire ainsi, on peut rejouer tous les autres évènements pour arriver à un étable véritable.
Snapshot
Le snapshot ou état de l’objet, est la représentation de l’état véritable à un moment précis dans le système. Nous allons donc avoir un processus pour sauvegarder à un point fixe un représentation de l’objet. Nous pouvons faire 2 procédures pour faire cela, utiliser un mécanisme de job exécuté à une cadence précise ou une procédure exécuter après un certain nombre d’évènement dans la pile d’évènement.
Pour garder les évènements dans l’application, nous avons plusieurs façons, un base de données, des logs d’audit, une pile en mémoire ou un event bus peuvent être des mécanisme pour persister ces évènements là.
Pourquoi toute cette complexité?
Alors que ça devient complexe d’avoir tous ces différents mécanismes pour pouvoir gérer au final quelque chose qui s’avère simple (état d’un objet), cela peut s’avérer être un solution pratique pour modéliser des processus d’affaire qui ont plusieurs affluents différents. Ainsi, nous pouvoir voir que s’il y a des cycliques d’évolution complexe dans le système, l’event source peut être utile. Dans des applications à haut niveau de performance attendu, cela peut s’avérer super puissant pour justement avoir une idée de l’évolution temporel d’un concept (grille télé en fonction des parties sportives) qui ne peut pas être prédictif où qui peut être influencé par plusieurs sources différentes. La gestion par évènements devient alors hyper intéressante.
Expliquez le Black Board. Donnez un exemple de cas d’utilisation.
Il y a un blackboard qui consiste en un repository de données. Un contrôleur d’accès sert de point d’entrée et effectue les interactions avec le blackboard. Le contrôleur d’accès est appelé par les diverses knowledge sources. Ex: Halo avec Master Chief comme blackboard et les Grunts comme knowledge sources.
