SlideShare une entreprise Scribd logo
Objectif Top Architecte !
Alexandre Touret : Architecte – EquensWorldline
Architecte
JAVA, API, CI, OPEN SOURCE
@touret_alex
https://blog.touret.info
https://blog.worldline.tech
Alexandre TOURET
Sommaire
La théorie (~40mn) La pratique (~50mn) Le comparatif (~20mn)
Qu’est-ce que l’architecture ?
Architecture represents the significant design decisions
that shape a system
Selon Grady Booch …
All architecture is design, but not all design is
architecture
Most architectures are accidental, not intensional
Tell us what is important. Architecture is about the
important stuff. Whatever that is.
The best code you can write now is code you’ll discard
in a couple of years
Selon Martin Fowler…
Comment devenir architecte?
Il y a des ouvrages et des formations …
La théorie ?
… Le mieux reste encore la pratique !
F. BROOKS ( Design of Design )
Un grand architecte ne se développe
que par la pratique
T. NEWARD
So how are we supposed to get great architects, if they
only get the chance to architect fewer than a half-dozen
times in their career?
Qu’est-ce qu’une bonne
architecture ?
se caractérise principalement par ces trois qualités
Une “bonne” architecture
Simplicité Evolutivité Adapté à l’environnement
Une bonne architecture :
répond au cahier des charges
sans être trop compliquée
sans bloquer l’avenir
Simplicité
Minimum Viable Architecture
Evolutivité
Approche
modulaire
Ouverture Travailler par
couches
Pensez aux contraintes de l’organisation
Est-ce qu’il y a une stratégie de rationalisation ?
Quelles sont les contraintes de sécurité ?
Est-ce que l’application doit être accessible ?
Quelles sont les contraintes d’ouverture de services ?
Principe de CONWAY
« les organisations qui définissent des systèmes ... sont
contraintes de les produire sous des designs qui sont des copies
de la structure de communication de leur organisation » (1967)
Adaptée à l’environnement
Dans la “vraie vie”…
Voyons comment tout ça s’articule dans un cycle projet …
Répondre aux questions suivantes :
Quels sont les résultats
attendus ?
01
Quels sont les chiffres clés ?
02
Pour démarrer
Quelles sont les
responsabilités ?
03
Les décrire dès le début !
Les résultats attendus
Pourquoi construire une nouvelle application ?
Quel est le produit attendu ?
Nous voulons construire une voiture de course
Les pneus sont les parties les plus importantes
Exemple par l’absurde
[TNT19] Hands on: Objectif Top Architecte!
Indiquer les différents éléments qui peuvent être
pertinents
Exemples
Mon application doit avoir un temps de réponse < 50ms
La volumétrie pourra être de 10To par an
Les chiffres clés
Responsible
Ceux qui réalisent
Accountable
Ceux qui sont responsables
Consultable
Ceux qui peuvent être consultés
Informed
Ceux qui doivent être informés
RACI
Méthode
• Un diagramme orienté système
• Un diagramme orienté conteneurs
• Un diagramme orienté composants
• Un diagramme UML
Méthode
Le modèle C4
(https://c4model.com/ )
Le formalisme
https://c4model.com/
Le modèle C4
Le modèle orienté conteneurs
(https://c4model.com/ )
Le modèle C4
Le modèle orienté composant
(https://c4model.com/ )
Prenez en considération le contexte de l’entreprise
Quelles sont les normes ?
Quels sont les standards de production ?
Est-ce qu’il y a une stratégie de rationalisation ?
Quel est le contexte réglementaire ( PCI DSS, GDPR,… ) ?
Conception
Utilisez des “recettes de cuisine”
Utilisez des patterns et solutions (re)connu.e.s
Si vous avez des solutions éprouvées qui correspondent au
besoin
Utilisez les !
Les patterns
et modèles d’architecture
MVC
1976
GOF
1994
Architecture N-Tier
1993
Architecture Orientée Services
Serveur1
Architecture Orientée Microservices
Serveur1 Serveur2
Serveur3 Serveur1
Serveur2
Architecture services
2000 ’s
<<Interface>>
Video Game Console
Tester
Arcade Box Switch PS4
Application1
Serveur 1
Application2
BUS
Serveur 2
Couplâge lâche
Au niveau logiciel
Chaque composant n’est accessible que par le contrat exposé par une interface
Au niveau intégration d’application
Chaque système est ( ou tend à être ) autonome
Architecture Hexagonale
Domain
Ce qu’on fournit à l’utilisateur
final.
GUI, API, ...
Le métier, les règles métier
Infrastructure
Application
Accès BDD, FS, WS externes,...
Circuit Breaker
Le circuit breaker permet de contrôler la collaboration entre différents services afin d’offrir
une grande tolérance à la latence et à l’échec.
Service 1 Service 2
Réponse alternative
Réponse alternative
Réponse attendue
OK
Erreur
500
Timeout
CQRS
Le pattern CQRS (Command Query Responsibility Segregation) repose sur un principe
simple : la séparation, au sein d'une application, des composants de traitement d’écriture
(« command ») et lecture (« query »).
Client
Modèle de commande
↑
→
Modèle de requête ←
↑
Evènement
Ecriture
Lecture
Mise à jour
Event Sourcing
L’Event Sourcing propose de se concentrer sur la séquence de changements d’état d’une
application qui a amené cette dernière dans l’état où elle se trouve.
On ne fait plus d’ update ou delete, mais seulement des créations d’évènements et lecture
.
Batch ou Temps réel ?
Ca dépend …
Du besoin et des contraintes
Penser aux reprises sur erreur
Est-ce qu’il y a une transaction à gérer ?
Quand est-ce que le traitement doit être déclenché ?
Développement
Pensez à la “testabilité” !
Une approche modulaire permet de tester “facilement”
chaque composant de manière isolée
Au niveau logiciel
Faites simple !
Automatisez le plus possible
Pensez à la production !
Aux logs, aux exceptions, aux contraintes
d’exécution,…
Les ADR
Architecture Decision Records
But :
Capturer les décisions d’architecture qui ont un impact et les tracer tout au
long du projet.
Exemple de fichier ADR au format
MARKDOWN .
Il peut être mis directement dans le projet
En Production
Choisissez les technologies que la production peut
maîtriser
Evitez d’associer une nouvelle stack et une nouvelle
application métier
Validez les chiffres clés émis pendant la conception
Les architecture katas
Ou comment adapter les coding dojos à l’architecture …
Plusieurs équipes
si possible avec répartition aléatoire
Chacune reçoit un kata différent
Pendant 1H : Travail sur le kata
Vous pouvez poser des questions !
Présentations des katas
5mn présentation + 5mn questions /réponses par équipe
Les katas
Sujet : Une organisation veut construire le plus grand arbre généalogique de l’histoire
Besoin: On souhaite visualiser des données sous la forme de graphes et y accéder via plusieurs
plateformes ( API, WEB, MOBILE,…)
On souhaite l’intégration avec les réseaux sociaux et les bases de données officielles pour intégrer
toutes ces données de manière automatique
Une modération humaine pourra être réalisée également
Volumétrie : des milliards d’enregistrements , des million de connexions et des connexions avec
d’autres applications
Qui est mon ancêtre ?
Sujet : Créer des sites automatiquement en fonction du buzz actuel
Besoin: Des clients souhaitent créer dynamiquement des sites web en fonction des tendances du
moment sur Internet ( réseaux sociaux, sites, forums,…). Ces sites doivent être pré remplis en
fonction du buzz et avoir une forte visibilité sur Internet (SEO) . Des administrateurs fonctionnels
pourront également compléter et/ou corriger le contenu.
Volumétrie: ??
Suivre le buzz
Sujet : Utiliser les capacités des voitures connectées pour identifier les routes à rénover
Besoin: Les collectivités territoriales ont du mal à identifier les routes à rénover et ont de moins en
moins de moyens. Du coup, elles souhaitent avoir des rapports dynamiques et précis sur l’utilisation
des routes à la journée. Les données proviendront des voitures. Le traitement des données doit être
anonymisé et compatible GDPR 
Volumétrie: 1 transaction par seconde par voiture
Les plus mauvaises routes
Sujet :Mettre en oeuvre une cave à vin connectée ainsi que son assistant personalisé
Besoin: On souhaite faire une cave à vin connectée qui permette la gestion des bouteilles ( date
d’arrivée, date de dégustation,…), qui indique quand la boire, les plats associés,…
L’ajout pourra se faire de manière automatique ( reconnaissance ?) ou manuelle
L’application doit disposer dans sa base de données de tous les vins français et internationaux.
Le tout centralisé, qui se connecte aux réseaux sociaux et permette des notifications ( SMS, mail,…)
….
Volumétrie: On cible à terme 1 million d’utilisateurs
Le nombre de transactions par seconde est très réduit
Une cave à vin connectée
Merci !
Alexandre Touret : Architecte – EquensWoldline
@touret_alex / #TNT19

Contenu connexe

Similaire à [TNT19] Hands on: Objectif Top Architecte!

Captronic grenoble 01102014 version presentee
Captronic grenoble 01102014 version presenteeCaptronic grenoble 01102014 version presentee
Captronic grenoble 01102014 version presentee
Patrick MOREAU
 
Kit De Survie Techno et Web à l'usage des Entrepreneurs
Kit De Survie Techno et Web à l'usage des EntrepreneursKit De Survie Techno et Web à l'usage des Entrepreneurs
Kit De Survie Techno et Web à l'usage des Entrepreneurs
Stéphanie Hertrich
 
OCTO Talks - State of the art Architecture dans les frontend web
OCTO Talks - State of the art Architecture dans les frontend webOCTO Talks - State of the art Architecture dans les frontend web
OCTO Talks - State of the art Architecture dans les frontend web
OCTO Technology
 
DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?
Ludovic Piot
 
SPINALBIM Suite: transformation digitale de l'exploitation et la maintenance
SPINALBIM Suite: transformation digitale de l'exploitation et la maintenanceSPINALBIM Suite: transformation digitale de l'exploitation et la maintenance
SPINALBIM Suite: transformation digitale de l'exploitation et la maintenance
Sebastien Coulon
 
Cahier de charges Site web DRUPAL
Cahier de charges Site web DRUPALCahier de charges Site web DRUPAL
Cahier de charges Site web DRUPAL
Laribi Aicha
 
Architecture MicroServices - DotNetTlse
Architecture MicroServices - DotNetTlseArchitecture MicroServices - DotNetTlse
Architecture MicroServices - DotNetTlse
Ionut Mihalcea
 
Visual Studio 2013 / SharePoint 2013 duo de choc de 2010 à 2013 en un clin d’œil
Visual Studio 2013 / SharePoint 2013 duo de choc de 2010 à 2013 en un clin d’œilVisual Studio 2013 / SharePoint 2013 duo de choc de 2010 à 2013 en un clin d’œil
Visual Studio 2013 / SharePoint 2013 duo de choc de 2010 à 2013 en un clin d’œil
Microsoft Technet France
 
SPA avec SignalR et Angular Js
SPA avec SignalR et Angular JsSPA avec SignalR et Angular Js
SPA avec SignalR et Angular Js
Microsoft
 
Architecture logicielle #1 : introduction
Architecture logicielle #1 : introductionArchitecture logicielle #1 : introduction
Architecture logicielle #1 : introduction
Jean Michel
 
8 trend dsi pharma vf
8 trend dsi pharma vf8 trend dsi pharma vf
8 trend dsi pharma vf
Bertrand Petit
 
Découvrez comment l’ECM peut concrètement « BOOSTER » votre entreprise à trav...
Découvrez comment l’ECM peut concrètement « BOOSTER » votre entreprise à trav...Découvrez comment l’ECM peut concrètement « BOOSTER » votre entreprise à trav...
Découvrez comment l’ECM peut concrètement « BOOSTER » votre entreprise à trav...
Microsoft Décideurs IT
 
La Duck Conf - "Quelle place pour le no code/low code dans les entreprises ?"
La Duck Conf - "Quelle place pour le no code/low code dans les entreprises ?"La Duck Conf - "Quelle place pour le no code/low code dans les entreprises ?"
La Duck Conf - "Quelle place pour le no code/low code dans les entreprises ?"
OCTO Technology
 
Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014
Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014
Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014
Marc Bourhis
 
System Center 2012 : Montez votre Cloud Privé avec NetApp et Cisco
System Center 2012 : Montez votre Cloud Privé avec NetApp et Cisco System Center 2012 : Montez votre Cloud Privé avec NetApp et Cisco
System Center 2012 : Montez votre Cloud Privé avec NetApp et Cisco
Microsoft Technet France
 
Competitive collaboratives solutions - Enjeux et Réponses
Competitive collaboratives solutions - Enjeux et RéponsesCompetitive collaboratives solutions - Enjeux et Réponses
Competitive collaboratives solutions - Enjeux et Réponses
Eric Herschkorn
 
Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !
Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !
Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !
Simplicité Software
 
Vers une nouvelle ère de vos expériences
Vers une nouvelle ère de vos expériencesVers une nouvelle ère de vos expériences
Vers une nouvelle ère de vos expériences
Fabernovel
 

Similaire à [TNT19] Hands on: Objectif Top Architecte! (20)

Captronic grenoble 01102014 version presentee
Captronic grenoble 01102014 version presenteeCaptronic grenoble 01102014 version presentee
Captronic grenoble 01102014 version presentee
 
bb-d_ERGO-UX
bb-d_ERGO-UXbb-d_ERGO-UX
bb-d_ERGO-UX
 
Kit De Survie Techno et Web à l'usage des Entrepreneurs
Kit De Survie Techno et Web à l'usage des EntrepreneursKit De Survie Techno et Web à l'usage des Entrepreneurs
Kit De Survie Techno et Web à l'usage des Entrepreneurs
 
OCTO Talks - State of the art Architecture dans les frontend web
OCTO Talks - State of the art Architecture dans les frontend webOCTO Talks - State of the art Architecture dans les frontend web
OCTO Talks - State of the art Architecture dans les frontend web
 
DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?
 
SPINALBIM Suite: transformation digitale de l'exploitation et la maintenance
SPINALBIM Suite: transformation digitale de l'exploitation et la maintenanceSPINALBIM Suite: transformation digitale de l'exploitation et la maintenance
SPINALBIM Suite: transformation digitale de l'exploitation et la maintenance
 
Cahier de charges Site web DRUPAL
Cahier de charges Site web DRUPALCahier de charges Site web DRUPAL
Cahier de charges Site web DRUPAL
 
Architecture MicroServices - DotNetTlse
Architecture MicroServices - DotNetTlseArchitecture MicroServices - DotNetTlse
Architecture MicroServices - DotNetTlse
 
Visual Studio 2013 / SharePoint 2013 duo de choc de 2010 à 2013 en un clin d’œil
Visual Studio 2013 / SharePoint 2013 duo de choc de 2010 à 2013 en un clin d’œilVisual Studio 2013 / SharePoint 2013 duo de choc de 2010 à 2013 en un clin d’œil
Visual Studio 2013 / SharePoint 2013 duo de choc de 2010 à 2013 en un clin d’œil
 
Debli technology 2
Debli technology 2Debli technology 2
Debli technology 2
 
SPA avec SignalR et Angular Js
SPA avec SignalR et Angular JsSPA avec SignalR et Angular Js
SPA avec SignalR et Angular Js
 
Architecture logicielle #1 : introduction
Architecture logicielle #1 : introductionArchitecture logicielle #1 : introduction
Architecture logicielle #1 : introduction
 
8 trend dsi pharma vf
8 trend dsi pharma vf8 trend dsi pharma vf
8 trend dsi pharma vf
 
Découvrez comment l’ECM peut concrètement « BOOSTER » votre entreprise à trav...
Découvrez comment l’ECM peut concrètement « BOOSTER » votre entreprise à trav...Découvrez comment l’ECM peut concrètement « BOOSTER » votre entreprise à trav...
Découvrez comment l’ECM peut concrètement « BOOSTER » votre entreprise à trav...
 
La Duck Conf - "Quelle place pour le no code/low code dans les entreprises ?"
La Duck Conf - "Quelle place pour le no code/low code dans les entreprises ?"La Duck Conf - "Quelle place pour le no code/low code dans les entreprises ?"
La Duck Conf - "Quelle place pour le no code/low code dans les entreprises ?"
 
Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014
Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014
Présentation du SOA et BPM par Rs2i_AtelierFocusInnovation_06022014
 
System Center 2012 : Montez votre Cloud Privé avec NetApp et Cisco
System Center 2012 : Montez votre Cloud Privé avec NetApp et Cisco System Center 2012 : Montez votre Cloud Privé avec NetApp et Cisco
System Center 2012 : Montez votre Cloud Privé avec NetApp et Cisco
 
Competitive collaboratives solutions - Enjeux et Réponses
Competitive collaboratives solutions - Enjeux et RéponsesCompetitive collaboratives solutions - Enjeux et Réponses
Competitive collaboratives solutions - Enjeux et Réponses
 
Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !
Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !
Meetup #1 low-code, Pourquoi ? Pour qui ? Comment ? Rencontrons-nous !
 
Vers une nouvelle ère de vos expériences
Vers une nouvelle ère de vos expériencesVers une nouvelle ère de vos expériences
Vers une nouvelle ère de vos expériences
 

Plus de Alexandre Touret

Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Alexandre Touret
 
Kubernetes & Co, beyond the hype
Kubernetes & Co, beyond the hypeKubernetes & Co, beyond the hype
Kubernetes & Co, beyond the hype
Alexandre Touret
 
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Alexandre Touret
 
[tours-jug19] Unifiez vos traitements Batch et Streaming avec Apache beam
[tours-jug19] Unifiez vos traitements Batch et Streaming avec Apache beam[tours-jug19] Unifiez vos traitements Batch et Streaming avec Apache beam
[tours-jug19] Unifiez vos traitements Batch et Streaming avec Apache beam
Alexandre Touret
 
[orleans-tech-19] Unifiez vos traitements Batch et Streaming avec Apache beam
[orleans-tech-19] Unifiez vos traitements Batch et Streaming avec Apache beam[orleans-tech-19] Unifiez vos traitements Batch et Streaming avec Apache beam
[orleans-tech-19] Unifiez vos traitements Batch et Streaming avec Apache beam
Alexandre Touret
 
Jenkins2 : le retour ( d'expérience) : TouraineTech 2018
Jenkins2 : le retour ( d'expérience) : TouraineTech 2018Jenkins2 : le retour ( d'expérience) : TouraineTech 2018
Jenkins2 : le retour ( d'expérience) : TouraineTech 2018
Alexandre Touret
 

Plus de Alexandre Touret (6)

Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
 
Kubernetes & Co, beyond the hype
Kubernetes & Co, beyond the hypeKubernetes & Co, beyond the hype
Kubernetes & Co, beyond the hype
 
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
Checklist pour concevoir une application dans le cloud.10 conseils à l'attent...
 
[tours-jug19] Unifiez vos traitements Batch et Streaming avec Apache beam
[tours-jug19] Unifiez vos traitements Batch et Streaming avec Apache beam[tours-jug19] Unifiez vos traitements Batch et Streaming avec Apache beam
[tours-jug19] Unifiez vos traitements Batch et Streaming avec Apache beam
 
[orleans-tech-19] Unifiez vos traitements Batch et Streaming avec Apache beam
[orleans-tech-19] Unifiez vos traitements Batch et Streaming avec Apache beam[orleans-tech-19] Unifiez vos traitements Batch et Streaming avec Apache beam
[orleans-tech-19] Unifiez vos traitements Batch et Streaming avec Apache beam
 
Jenkins2 : le retour ( d'expérience) : TouraineTech 2018
Jenkins2 : le retour ( d'expérience) : TouraineTech 2018Jenkins2 : le retour ( d'expérience) : TouraineTech 2018
Jenkins2 : le retour ( d'expérience) : TouraineTech 2018
 

[TNT19] Hands on: Objectif Top Architecte!

  • 1. Objectif Top Architecte ! Alexandre Touret : Architecte – EquensWorldline
  • 2. Architecte JAVA, API, CI, OPEN SOURCE @touret_alex https://blog.touret.info https://blog.worldline.tech Alexandre TOURET
  • 3. Sommaire La théorie (~40mn) La pratique (~50mn) Le comparatif (~20mn)
  • 5. Architecture represents the significant design decisions that shape a system Selon Grady Booch … All architecture is design, but not all design is architecture Most architectures are accidental, not intensional
  • 6. Tell us what is important. Architecture is about the important stuff. Whatever that is. The best code you can write now is code you’ll discard in a couple of years Selon Martin Fowler…
  • 8. Il y a des ouvrages et des formations … La théorie ? … Le mieux reste encore la pratique ! F. BROOKS ( Design of Design ) Un grand architecte ne se développe que par la pratique T. NEWARD So how are we supposed to get great architects, if they only get the chance to architect fewer than a half-dozen times in their career?
  • 10. se caractérise principalement par ces trois qualités Une “bonne” architecture Simplicité Evolutivité Adapté à l’environnement
  • 11. Une bonne architecture : répond au cahier des charges sans être trop compliquée sans bloquer l’avenir Simplicité
  • 14. Pensez aux contraintes de l’organisation Est-ce qu’il y a une stratégie de rationalisation ? Quelles sont les contraintes de sécurité ? Est-ce que l’application doit être accessible ? Quelles sont les contraintes d’ouverture de services ? Principe de CONWAY « les organisations qui définissent des systèmes ... sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation » (1967) Adaptée à l’environnement
  • 15. Dans la “vraie vie”… Voyons comment tout ça s’articule dans un cycle projet …
  • 16. Répondre aux questions suivantes : Quels sont les résultats attendus ? 01 Quels sont les chiffres clés ? 02 Pour démarrer Quelles sont les responsabilités ? 03
  • 17. Les décrire dès le début ! Les résultats attendus Pourquoi construire une nouvelle application ? Quel est le produit attendu ?
  • 18. Nous voulons construire une voiture de course Les pneus sont les parties les plus importantes Exemple par l’absurde
  • 20. Indiquer les différents éléments qui peuvent être pertinents Exemples Mon application doit avoir un temps de réponse < 50ms La volumétrie pourra être de 10To par an Les chiffres clés
  • 21. Responsible Ceux qui réalisent Accountable Ceux qui sont responsables Consultable Ceux qui peuvent être consultés Informed Ceux qui doivent être informés RACI
  • 23. • Un diagramme orienté système • Un diagramme orienté conteneurs • Un diagramme orienté composants • Un diagramme UML Méthode Le modèle C4 (https://c4model.com/ )
  • 25. Le modèle C4 Le modèle orienté conteneurs (https://c4model.com/ )
  • 26. Le modèle C4 Le modèle orienté composant (https://c4model.com/ )
  • 27. Prenez en considération le contexte de l’entreprise Quelles sont les normes ? Quels sont les standards de production ? Est-ce qu’il y a une stratégie de rationalisation ? Quel est le contexte réglementaire ( PCI DSS, GDPR,… ) ? Conception Utilisez des “recettes de cuisine” Utilisez des patterns et solutions (re)connu.e.s Si vous avez des solutions éprouvées qui correspondent au besoin Utilisez les !
  • 28. Les patterns et modèles d’architecture
  • 32. Architecture Orientée Services Serveur1 Architecture Orientée Microservices Serveur1 Serveur2 Serveur3 Serveur1 Serveur2 Architecture services 2000 ’s
  • 33. <<Interface>> Video Game Console Tester Arcade Box Switch PS4 Application1 Serveur 1 Application2 BUS Serveur 2 Couplâge lâche Au niveau logiciel Chaque composant n’est accessible que par le contrat exposé par une interface Au niveau intégration d’application Chaque système est ( ou tend à être ) autonome
  • 34. Architecture Hexagonale Domain Ce qu’on fournit à l’utilisateur final. GUI, API, ... Le métier, les règles métier Infrastructure Application Accès BDD, FS, WS externes,...
  • 35. Circuit Breaker Le circuit breaker permet de contrôler la collaboration entre différents services afin d’offrir une grande tolérance à la latence et à l’échec. Service 1 Service 2 Réponse alternative Réponse alternative Réponse attendue OK Erreur 500 Timeout
  • 36. CQRS Le pattern CQRS (Command Query Responsibility Segregation) repose sur un principe simple : la séparation, au sein d'une application, des composants de traitement d’écriture (« command ») et lecture (« query »). Client Modèle de commande ↑ → Modèle de requête ← ↑ Evènement Ecriture Lecture Mise à jour
  • 37. Event Sourcing L’Event Sourcing propose de se concentrer sur la séquence de changements d’état d’une application qui a amené cette dernière dans l’état où elle se trouve. On ne fait plus d’ update ou delete, mais seulement des créations d’évènements et lecture .
  • 38. Batch ou Temps réel ? Ca dépend … Du besoin et des contraintes Penser aux reprises sur erreur Est-ce qu’il y a une transaction à gérer ? Quand est-ce que le traitement doit être déclenché ?
  • 39. Développement Pensez à la “testabilité” ! Une approche modulaire permet de tester “facilement” chaque composant de manière isolée Au niveau logiciel Faites simple ! Automatisez le plus possible Pensez à la production ! Aux logs, aux exceptions, aux contraintes d’exécution,…
  • 40. Les ADR Architecture Decision Records But : Capturer les décisions d’architecture qui ont un impact et les tracer tout au long du projet. Exemple de fichier ADR au format MARKDOWN . Il peut être mis directement dans le projet
  • 41. En Production Choisissez les technologies que la production peut maîtriser Evitez d’associer une nouvelle stack et une nouvelle application métier Validez les chiffres clés émis pendant la conception
  • 42. Les architecture katas Ou comment adapter les coding dojos à l’architecture …
  • 43. Plusieurs équipes si possible avec répartition aléatoire Chacune reçoit un kata différent Pendant 1H : Travail sur le kata Vous pouvez poser des questions ! Présentations des katas 5mn présentation + 5mn questions /réponses par équipe Les katas
  • 44. Sujet : Une organisation veut construire le plus grand arbre généalogique de l’histoire Besoin: On souhaite visualiser des données sous la forme de graphes et y accéder via plusieurs plateformes ( API, WEB, MOBILE,…) On souhaite l’intégration avec les réseaux sociaux et les bases de données officielles pour intégrer toutes ces données de manière automatique Une modération humaine pourra être réalisée également Volumétrie : des milliards d’enregistrements , des million de connexions et des connexions avec d’autres applications Qui est mon ancêtre ?
  • 45. Sujet : Créer des sites automatiquement en fonction du buzz actuel Besoin: Des clients souhaitent créer dynamiquement des sites web en fonction des tendances du moment sur Internet ( réseaux sociaux, sites, forums,…). Ces sites doivent être pré remplis en fonction du buzz et avoir une forte visibilité sur Internet (SEO) . Des administrateurs fonctionnels pourront également compléter et/ou corriger le contenu. Volumétrie: ?? Suivre le buzz
  • 46. Sujet : Utiliser les capacités des voitures connectées pour identifier les routes à rénover Besoin: Les collectivités territoriales ont du mal à identifier les routes à rénover et ont de moins en moins de moyens. Du coup, elles souhaitent avoir des rapports dynamiques et précis sur l’utilisation des routes à la journée. Les données proviendront des voitures. Le traitement des données doit être anonymisé et compatible GDPR  Volumétrie: 1 transaction par seconde par voiture Les plus mauvaises routes
  • 47. Sujet :Mettre en oeuvre une cave à vin connectée ainsi que son assistant personalisé Besoin: On souhaite faire une cave à vin connectée qui permette la gestion des bouteilles ( date d’arrivée, date de dégustation,…), qui indique quand la boire, les plats associés,… L’ajout pourra se faire de manière automatique ( reconnaissance ?) ou manuelle L’application doit disposer dans sa base de données de tous les vins français et internationaux. Le tout centralisé, qui se connecte aux réseaux sociaux et permette des notifications ( SMS, mail,…) …. Volumétrie: On cible à terme 1 million d’utilisateurs Le nombre de transactions par seconde est très réduit Une cave à vin connectée
  • 48. Merci ! Alexandre Touret : Architecte – EquensWoldline @touret_alex / #TNT19

Notes de l'éditeur

  1. Retrouver un logo plus propre
  2. Demander qui parmi l’assistance est architecte ou a déjà défini une archi ?
  3. Indiquer que TED NEWARD a lancé des katas d’architecture permettant de pratiquer à l’instar des coding dojos
  4. Hôtel Vdara de Las Vegas Pour être joli il est joli l'hôtel Vdara, tout incurvé comme il faut, tout brillant. Peu de temps après son ouverture cependant, des clients ont commencé à se plaindre, comme quoi quand ils allaient à la piscine leurs cheveux prenaient feu et les sacs se mettaient à fondre. Pourquoi ? Parce que la grande surface vitrée de l'immeuble faisait un effet loupe et cramait un peu tout. Si vous y allez, pensez donc à prendre une bonne crème solaire.
  5. Notion apparue et mise en avant avec les méthodes agiles. Il y a la notion du MVP Most Valuable Product A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.[1][2] Gathering insights from an MVP is often less expensive than developing a product with more features, which increases costs and risk if the product fails, for example, due to incorrect assumptions. The term was coined and defined by Frank Robinson about 2001,[3] and popularized by Steve Blank and Eric Ries.[4][5][6][7] It may also involve carrying out market analysis beforehand. On ne cherche pas à construire tout de suite la voiture dans notre cas : on construit progressivement
  6. Approche modulaire : Indiquer qu’il faut découper l’application en modules mais pas trop finement. Ne découper qu’en modules qui pourront être livrés ( si il faut faire des couches communes, créer une dépendance) Ils doivent être testables indépendamment Faire attention aux frameworks structurants Les couches … pas faire de SQL directement dans la couche client Ouverture : c’est ce qui permet de rendre évolutif. Utiliser des protocoles ouverts, basés sur des normes standardisées.
  7. Bien dire que l’objectif n’est pas de se calquer sur ce qui est déjà fait mais de bien le prendre en compte Pas la peine de vouloir déployer une archi server less si l’entreprise n’est pas prête ( production, exploitation ) Les contraintes ne sont pas les mêmes en fonction du business ( mutuelle, paiement bancaire )
  8. Dire que depuis qq années, j’utilise la formule Amazon
  9. Si vous faites une étude d’architecture , commencez par les résultats attendus. Ils vous guideront dans le choix d’architecture à préconiser
  10. On ne dirait pas comme ça, mais c’est très important… ( CONNWAY ) cela permet d’identifier qui valide vos hypothèses et l’architecture
  11. Level 1: System Context diagram A System Context diagram is a good starting point for diagramming and documenting a software system, allowing you to step back and see the big picture. Draw a diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interacts with. Detail isn't important here as this is your zoomed out view showing a big picture of the system landscape. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It's the sort of diagram that you could show to non-technical people. Scope: A single software system. Primary elements: The software system in scope. Supporting elements: People and software systems directly connected to the software system in scope. Intended audience: Everybody, both technical and non-technical people, inside and outside of the software development team. Level 2: Container diagram Once you understand how your system fits in to the overall IT environment, a really useful next step is to zoom-in to the system boundary with a Container diagram. A "container" is something like a server-side web application, single-page application, desktop application, mobile app, database schema, file system, etc. Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data. The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It's a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike. Scope: A single software system. Primary elements: Containers within the software system in scope. Supporting elements: People and software systems directly connected to the containers. Intended audience: Technical people inside and outside of the software development team; including software architects, developers and operations/support staff. Notes: This diagram says nothing about deployment scenarios, clustering, replication, failover, etc. Level 3: Component diagram Next you can zoom in and decompose each container further to identify the major structural building blocks and their interactions. The Component diagram shows how a container is made up of a number of "components", what each of those components are, their responsibilities and the technology/implementation details. Scope: A single container. Primary elements: Components within the container in scope. Supporting elements: Containers (within the software system in scope) plus people and software systems directly connected to the components. Intended audience: Software architects and developers. Level 4: Code Finally, you can zoom in to each component to show how it is implemented as code; using UML class diagrams, entity relationship diagrams or similar. This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally this diagram would be automatically generated using tooling (e.g. an IDE or UML modelling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components. Scope: A single component. Primary elements: Code elements (e.g. classes, interfaces, objects, functions, database tables, etc) within the component in scope. Intended audience: Software architects and developers.
  12. Level 1: System Context diagram A System Context diagram is a good starting point for diagramming and documenting a software system, allowing you to step back and see the big picture. Draw a diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interacts with. Detail isn't important here as this is your zoomed out view showing a big picture of the system landscape. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It's the sort of diagram that you could show to non-technical people. Scope: A single software system. Primary elements: The software system in scope. Supporting elements: People and software systems directly connected to the software system in scope. Intended audience: Everybody, both technical and non-technical people, inside and outside of the software development team. Level 2: Container diagram Once you understand how your system fits in to the overall IT environment, a really useful next step is to zoom-in to the system boundary with a Container diagram. A "container" is something like a server-side web application, single-page application, desktop application, mobile app, database schema, file system, etc. Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data. The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It's a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike. Scope: A single software system. Primary elements: Containers within the software system in scope. Supporting elements: People and software systems directly connected to the containers. Intended audience: Technical people inside and outside of the software development team; including software architects, developers and operations/support staff. Notes: This diagram says nothing about deployment scenarios, clustering, replication, failover, etc. Level 3: Component diagram Next you can zoom in and decompose each container further to identify the major structural building blocks and their interactions. The Component diagram shows how a container is made up of a number of "components", what each of those components are, their responsibilities and the technology/implementation details. Scope: A single container. Primary elements: Components within the container in scope. Supporting elements: Containers (within the software system in scope) plus people and software systems directly connected to the components. Intended audience: Software architects and developers. Level 4: Code Finally, you can zoom in to each component to show how it is implemented as code; using UML class diagrams, entity relationship diagrams or similar. This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally this diagram would be automatically generated using tooling (e.g. an IDE or UML modelling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components. Scope: A single component. Primary elements: Code elements (e.g. classes, interfaces, objects, functions, database tables, etc) within the component in scope. Intended audience: Software architects and developers.
  13. Level 1: System Context diagram A System Context diagram is a good starting point for diagramming and documenting a software system, allowing you to step back and see the big picture. Draw a diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interacts with. Detail isn't important here as this is your zoomed out view showing a big picture of the system landscape. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It's the sort of diagram that you could show to non-technical people. Scope: A single software system. Primary elements: The software system in scope. Supporting elements: People and software systems directly connected to the software system in scope. Intended audience: Everybody, both technical and non-technical people, inside and outside of the software development team. Level 2: Container diagram Once you understand how your system fits in to the overall IT environment, a really useful next step is to zoom-in to the system boundary with a Container diagram. A "container" is something like a server-side web application, single-page application, desktop application, mobile app, database schema, file system, etc. Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data. The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It's a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike. Scope: A single software system. Primary elements: Containers within the software system in scope. Supporting elements: People and software systems directly connected to the containers. Intended audience: Technical people inside and outside of the software development team; including software architects, developers and operations/support staff. Notes: This diagram says nothing about deployment scenarios, clustering, replication, failover, etc. Level 3: Component diagram Next you can zoom in and decompose each container further to identify the major structural building blocks and their interactions. The Component diagram shows how a container is made up of a number of "components", what each of those components are, their responsibilities and the technology/implementation details. Scope: A single container. Primary elements: Components within the container in scope. Supporting elements: Containers (within the software system in scope) plus people and software systems directly connected to the components. Intended audience: Software architects and developers. Level 4: Code Finally, you can zoom in to each component to show how it is implemented as code; using UML class diagrams, entity relationship diagrams or similar. This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally this diagram would be automatically generated using tooling (e.g. an IDE or UML modelling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components. Scope: A single component. Primary elements: Code elements (e.g. classes, interfaces, objects, functions, database tables, etc) within the component in scope. Intended audience: Software architects and developers.
  14. Level 1: System Context diagram A System Context diagram is a good starting point for diagramming and documenting a software system, allowing you to step back and see the big picture. Draw a diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interacts with. Detail isn't important here as this is your zoomed out view showing a big picture of the system landscape. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It's the sort of diagram that you could show to non-technical people. Scope: A single software system. Primary elements: The software system in scope. Supporting elements: People and software systems directly connected to the software system in scope. Intended audience: Everybody, both technical and non-technical people, inside and outside of the software development team. Level 2: Container diagram Once you understand how your system fits in to the overall IT environment, a really useful next step is to zoom-in to the system boundary with a Container diagram. A "container" is something like a server-side web application, single-page application, desktop application, mobile app, database schema, file system, etc. Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data. The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It's a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike. Scope: A single software system. Primary elements: Containers within the software system in scope. Supporting elements: People and software systems directly connected to the containers. Intended audience: Technical people inside and outside of the software development team; including software architects, developers and operations/support staff. Notes: This diagram says nothing about deployment scenarios, clustering, replication, failover, etc. Level 3: Component diagram Next you can zoom in and decompose each container further to identify the major structural building blocks and their interactions. The Component diagram shows how a container is made up of a number of "components", what each of those components are, their responsibilities and the technology/implementation details. Scope: A single container. Primary elements: Components within the container in scope. Supporting elements: Containers (within the software system in scope) plus people and software systems directly connected to the components. Intended audience: Software architects and developers. Level 4: Code Finally, you can zoom in to each component to show how it is implemented as code; using UML class diagrams, entity relationship diagrams or similar. This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally this diagram would be automatically generated using tooling (e.g. an IDE or UML modelling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components. Scope: A single component. Primary elements: Code elements (e.g. classes, interfaces, objects, functions, database tables, etc) within the component in scope. Intended audience: Software architects and developers.
  15. Importance des conférences
  16. Au niveau logiciel Cela offre une indépendance entre les implémentations réalisées et le contrat d’interface fournis aux clients Parler de l’IOC Au niveau intégration application ( système) Les différents systèmes échangent des données soit par services soit via un BUS en s’appuyant sur un standard commun Advantages and disadvantages Components in a loosely coupled system can be replaced with alternative implementations that provide the same services. Components in a loosely coupled system are less constrained to the same platform, language, operating system, or build environment. If systems are decoupled in time, it is difficult to also provide transactional integrity; additional coordination protocols are required. Data replication across different systems provides loose coupling (in availability), but creates issues in maintaining consistency (data synchronization). Inconvénients d'un couplage fort Un couplage fort est à proscrire pour plusieurs raisons : Un couplage fort génère l'antipattern plat de spaghetti : On ne peut pas déterminer le qui, le quoi et le comment d’une modification de données. Un couplage fort implique nécessairement une faible indépendance fonctionnelle : Le composant logiciel est difficilement réutilisable, Le composant logiciel est difficilement testable. Si deux tâches accèdent, par couplage fort, à une ressource commune (ressource critique) et qu'elles s'exécutent en exclusion mutuelle, alors si une des tâches reste bloquée en section critique elle bloque automatiquement l'autre : Risque d'interblocage. Les composants perdent leur autonomie. On peut difficilement remplacer un composant par un autre. Les structures fonctionnant avec du couplage fort sont donc peu souples et peu ouvertes. Solution L'idée générale du couplage faible consiste à établir un protocole d'échange et à effectuer le moins d'hypothèses (ou à imposer le moins de contraintes) possible entre les composants. Ainsi, les composants interagissent dans un cadre défini. Une métaphore classique est celle de la prise électrique qui est un standard pour le branchement d'appareils électriques. Cela se traduit en informatique par le concept de plugin.
  17. L’architecture hexagonale s’appuie sur trois principes et techniques : Séparer explicitement Application, Domain, et Infrastructure Les dépendances vont vers le Domain On isole les frontières par des Ports et Adapters À gauche, le côté Application C’est le côté par lequel l’utilisateur ou les programmes extérieurs vont interagir avec l’application. On y trouve le code qui permet ces interactions. Typiquement, votre code d’interface utilisateur, vos routes HTTP pour une API, vos sérialisations en JSON à destination de programmes qui consomment votre application sont ici. C’est le côté où l’on retrouve les acteurs qui pilotent le Domain. Note : Alistair Cockburn parle de Left Side, ou User Side pour le côté Application. Au centre, le Domain C’est la partie que l’on veut isoler de ce qui est à gauche et à droite. On y trouve tout le code qui concerne et implémente la logique métier. Le vocabulaire métier et la logique purement métier, ce qui se rapporte au problème concret que résout votre application, tout ce qui en fait la richesse et la spécificité est au centre. Dans l’idéal, un expert du métier qui ne sait pas coder pourrait lire un bout de code de cette partie et vous pointer une incohérence (true story, ce sont des choses qui pourraient vous arriver !). Note : Alistair Cockburn parle de Center, ou de Business Logic pour le Domain. À droite, le côté Infrastructure C’est ici qu’on va retrouver ce dont votre application a besoin, ce qu’elle pilote pour fonctionner. On y trouve les détails d’infrastructure essentiels comme le code qui interagit avec votre base de données, les appels au système de fichier, ou le code qui gère des appels HTTP à d’autres applications dont vous dépendez par exemple. C’est le côté où l’on retrouve les acteurs qui sont pilotés par le Domain. Note : Alistair Cockburn parle de Right Side, ou de Server Side pour le côté Infrastructure. Les principes qui suivent vont permettre de mettre en pratique cette séparation logique entre Application, Domain et Infrastructure. Pourquoi c’est important ? Une première caractéristique importante de cette séparation est qu’elle sépare les problèmes. À tout moment, on peut choisir de se concentrer sur une seule logique, presque indépendamment des deux autres : la logique applicative, la logique métier, ou la logique infrastructure. On les comprend plus facilement sans les mélanger, et les contraintes de chaque logique a moins d’impact sur les autres. Une autre caractéristique est qu’on met la logique métier en avant dans notre code.
  18. Pour cela, en fonction d’un certain nombre de critères d’erreur (timeout, nombre d’erreurs, élément dans la réponse), ce pattern permet de désactiver l’envoi de requêtes au service appelé et de renvoyer plus rapidement une réponse alternative de repli (fallback), aussi appelé graceful degradation.
  19. Advantages and disadvantages Components in a loosely coupled system can be replaced with alternative implementations that provide the same services. Components in a loosely coupled system are less constrained to the same platform, language, operating system, or build environment. If systems are decoupled in time, it is difficult to also provide transactional integrity; additional coordination protocols are required. Data replication across different systems provides loose coupling (in availability), but creates issues in maintaining consistency (data synchronization). Inconvénients d'un couplage fort Un couplage fort est à proscrire pour plusieurs raisons : Un couplage fort génère l'antipattern plat de spaghetti : On ne peut pas déterminer le qui, le quoi et le comment d’une modification de données. Un couplage fort implique nécessairement une faible indépendance fonctionnelle : Le composant logiciel est difficilement réutilisable, Le composant logiciel est difficilement testable. Si deux tâches accèdent, par couplage fort, à une ressource commune (ressource critique) et qu'elles s'exécutent en exclusion mutuelle, alors si une des tâches reste bloquée en section critique elle bloque automatiquement l'autre : Risque d'interblocage. Les composants perdent leur autonomie. On peut difficilement remplacer un composant par un autre. Les structures fonctionnant avec du couplage fort sont donc peu souples et peu ouvertes. Solution L'idée générale du couplage faible consiste à établir un protocole d'échange et à effectuer le moins d'hypothèses (ou à imposer le moins de contraintes) possible entre les composants. Ainsi, les composants interagissent dans un cadre défini. Une métaphore classique est celle de la prise électrique qui est un standard pour le branchement d'appareils électriques. Cela se traduit en informatique par le concept de plugin.
  20. d’audit : il est aisé de retrouver les effets d’actions du passé. Cela a beaucoup de valeur dans les contextes métiers où les régulateurs prennent une place importante (la finance, par exemple). d’analyse/debug : il est aisé de comprendre les évènements qui ont amené à tel ou tel bug. Quand on sait que le temps consacré à la correction d’un bug est majoritairement perdu dans des tentatives de reproductions infructueuses… de reprise de données : que ce soit en cas de panne (revenir dans l’état précédent la panne) ou pour reproduire un bug sur un autre environnement. Réplication base
  21. Décisionnel : on va partir sur du batch Après il faut aussi orienter le débat: des fois on a des « traditions » dans des sociétées qui sont orientées batch et qui se retrouvent avec des nuits batch qui débordent….
  22. Indiquer que l’on peut organiser le code d’une manière simple ( 1 projet -> 1 livrable ) faire d’abord un packaging fonctionnel puis technique permet de faciliter le refactoring
  23. Dire que ça ne sert pas à grand-chose de faire une archi serverless si la production ne connait que JEE/WEBLOGIC Faites d’abord installer et valider votre stack (ex. Docker ) par la production avant d’envisager le déploiement d’une application métier Cette validation pourra en plus des logs, de s’assurer que l’application soit fiable.
  24. Ted NEWARD a lancé ce concept et popularisé cette idée. Le but est de pratiquer sur des sujets éloignés de notre quotidien. Livrer une archi dans un minimum de temps qui puisse se lire, être comprise et présentée à d’autres personnes. Travailler sur la collaboration , confronter les idées , concevoir ensemble et se faire challenger 
  25. Rappel des besoins chiffres clés 1 diagramme système / containeur suffit ( en fonction de ce qui a présenter )