Révision Glossaire EN

Taille

Yeux

Termine une partie dans un dojo pour débloquer les yeux suivants.

Deviens architecte, dix minutes par jour.

Un chapitre par jour, sur du vrai code open source. Une question réussie revient 1, 3, 7, 21 puis 45 jours plus tard.

Aujourd’hui · jour 1 · 10 min

L’architecture logicielle : les décisions coûteuses à changer
Commencer la lecture →

0 chapitre sur 40 terminé

Penser en architecte : 0 sur 5Voir le système : 0 sur 4À l’intérieur d’un service : 0 sur 4Entre les services : 0 sur 6Domaines et frontières : 0 sur 3La boîte à patterns : 0 sur 8Le métier d’architecte : 0 sur 5Fait pour durer : 0 sur 5
Un pilier par partie. Il se remplit à mesure que tu finis ses chapitres.

Le parcours

Penser en architecte : 0 sur 5Penser en architecte

  1. L’architecture logicielle : les décisions coûteuses à changer 1
  2. Les caractéristiques d’architecture : choisir les trois principales 2
  3. Les scénarios de qualité : rendre « sécurisé » testable 3
  4. Les ADR : écrire le pourquoi d’une décision 4
  5. Les décisions réversibles : portes à sens unique et à double sens 5

Voir le système : 0 sur 4Voir le système

  1. Le diagramme de contexte : ton système en une seule boîte 6
  2. Les conteneurs : ce qui tourne vraiment 7
  3. Suivre une requête de bout en bout 8
  4. Le déploiement : des boîtes sur des machines 9

À l’intérieur d’un service : 0 sur 4À l’intérieur d’un service

  1. Les couches : les imports ne vont que dans un sens 10
  2. Ports et adaptateurs : un seul cœur, plusieurs backends 11
  3. Couplage et cohésion dans un service de checkout 12
  4. Multi-tenant : à qui sont ces données ? 13

Entre les services : 0 sur 6Entre les services

  1. Appels synchrones ou jobs asynchrones 14
  2. L’échec : timeouts, retries, idempotence 15
  3. La cohérence entre plusieurs stockages 16
  4. À qui appartiennent les données 17
  5. Gateways, tokens et SSO 18
  6. Le cache 19

Domaines et frontières : 0 sur 3Domaines et frontières

  1. Sous-domaines cœur, support et générique 20
  2. Bounded contexts et context maps 21
  3. Les styles d’architecture 22

La boîte à patterns : 0 sur 8La boîte à patterns

  1. SOLID : cinq principes, lus sur du vrai code 23
  2. Design patterns : des formes nommées que tu utilises déjà 24
  3. Les briques du DDD : à l’intérieur d’un bounded context 25
  4. Messaging : files, garanties de livraison et dead letters 26
  5. Outbox et sagas : quand un changement touche deux systèmes 27
  6. CQRS et event sourcing 28
  7. Résilience : empêcher une panne de se propager 29
  8. Observabilité : logs, métriques, traces 30

Fait pour durer : 0 sur 5Fait pour durer

  1. Conception et versionnement d’API 31
  2. Migrations de schéma et de données 32
  3. Modélisation des menaces 33
  4. Faire grandir les données 34
  5. Stratégie de test 35

Le métier d’architecte : 0 sur 5Le métier d’architecte

  1. Fitness functions : des décisions qui se vérifient toutes seules 36
  2. Faire évoluer un système en marche sans l’arrêter 37
  3. Relire un design : scénarios, portes, pannes 38
  4. Une décision, trois publics 39
  5. Ton premier kata : un design complet en 15 minutes 40