Trois façons de découper un système
Une architecture logicielle est le plan général d'un système : ses grandes parties, et la façon dont elles se parlent. Trois styles reviennent souvent : les couches, les services et les événements.
Chacun répond à des besoins différents. Vous allez apprendre à choisir selon les besoins du système, pas selon la mode du moment.
À la fin de cette leçon
Remarque
Je peux choisir entre des couches, des services ou des événements selon les besoins d'un système.
Mots clés
| Mot | Ce que ça veut dire | Exemple |
|---|---|---|
| Architecture | le plan général : les grandes parties et leurs échanges | |
| Couche | un étage du système qui sert celui du dessus | accès aux données |
| Service | un petit programme mis en route à part, qui répond à des appels | |
| Événement | le message qui annonce un fait déjà arrivé | réservation confirmée |
| Déploiement | la mise en route d'une nouvelle version du programme |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Des couches empilées, chacune sert celle du dessus
Dans une architecture en couches, on empile des étages. L'écran appelle les règles. Les règles appellent l'accès aux données. Chaque couche ne parle qu'à celle qui est juste en dessous.
On change une couche sans toucher aux autres, tant que son interface reste la même.
Des services séparés, livrés à leur rythme
Un service est un petit programme avec un rôle : les réservations, les comptes, les courriels. Il tourne à part et répond à des appels par le réseau.
Chaque équipe peut livrer son service sans attendre les autres. En échange, chaque appel peut échouer ou arriver en retard.
Exemple : couches et services côte à côte
| Question | Couches | Services |
|---|---|---|
| Combien de programmes ? | Un seul | Plusieurs |
| Un appel entre parties | Dans la mémoire | Par le réseau |
| Une équipe livre seule ? | Non | Oui |
| Que peut-il arriver ? | Une erreur dans le code | Un service en panne |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Une erreur fréquente
Attention
Beaucoup pensent que les services valent toujours mieux que les couches. Ils ajoutent des appels réseau et des pannes à gérer. Choisissez-les quand des équipes ou des rythmes de livraison différents l'exigent.
Un événement annonce un fait, et d'autres réagissent
Un événement dit qu'un fait vient d'arriver : « réservation confirmée ». Celui qui le publie ne sait pas qui l'écoute. Chaque partie intéressée réagit à sa façon.
On ajoute une réaction sans toucher à celui qui publie. En échange, il est plus dur de suivre ce qui se passe, car rien ne dit qui a réagi.
Exemple : quel style pour quel besoin
| Besoin | Style qui convient |
|---|---|
| Une équipe, un déploiement, des règles simples | Couches |
| Plusieurs équipes, livraisons séparées | Services |
| Plusieurs parties réagissent au même fait | Événements |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Le laboratoire est déjà deux services
Le laboratoire a deux services : la base et l'API. L'API est une couche entre le client et la base. On peut atteindre les mêmes données par les deux portes.
Préparez la table avec les cinq premiers Runs. Puis lisez-la par l'API, directement, et changez le statut d'une réservation.
Donner le mot de passe à psql
export PGPASSWORD=shopAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Repartir de zéro
psql -h db -U shop -c "drop table if exists reservations"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Créer la table reservations
psql -h db -U shop -c "create table reservations (id serial primary key, salle text not null, demandeur text not null, creneau text not null, statut text not null default 'demandee')"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Ajouter trois réservations
psql -h db -U shop -c "insert into reservations (salle, demandeur, creneau) values ('B102', 'Claire Dupuis', 'lundi 10h'), ('A201', 'Marc Lefebvre', 'lundi 10h'), ('B102', 'Sophie Martin', 'mardi 14h')"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Dire à l'API de relire la base
psql -h db -U shop -c "notify pgrst, 'reload schema'"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Lire par la porte de l'API
curl -s -o /dev/null -w "%{http_code}\n" "http://api:3000/reservations"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Compter par la porte de la base
psql -h db -U shop -t -A -c "select count(*) from reservations"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Confirmer la réservation 1 par l'API
curl -s -o /dev/null -w "%{http_code}\n" -X PATCH -H "Content-Type: application/json" -d '{"statut":"confirmee"}' "http://api:3000/reservations?id=eq.1"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Relire le statut dans la base
psql -h db -U shop -t -A -c "select statut from reservations where id = 1"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Un fait est arrivé, et personne n'est prévenu
La réservation 1 est passée à confirmée : c'est un fait. Dans une architecture par événements, ce fait serait publié, et le courriel et le calendrier le recevraient.
Ici, rien ne le publie. Si l'enseignant doit être prévenu, c'est une exigence de plus, et elle pousse vers les événements.