Recommandé
Recommandé
Contenu connexe
Similaire à [TNT19] Hands on: Objectif Top Architecte!
Similaire à [TNT19] Hands on: Objectif Top Architecte! (20)
Plus de Alexandre Touret
Plus de Alexandre Touret (6)
[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
- 22. Méthode
- 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
- 29. MVC 1976
- 30. GOF 1994
- 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
- Retrouver un logo plus propre
- Demander qui parmi l’assistance est architecte ou a déjà défini une archi ?
- Indiquer que TED NEWARD a lancé des katas d’architecture permettant de pratiquer à l’instar des coding dojos
- 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.
- 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
- 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.
- 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 )
- Dire que depuis qq années, j’utilise la formule Amazon
- Si vous faites une étude d’architecture , commencez par les résultats attendus. Ils vous guideront dans le choix d’architecture à préconiser
- 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
- 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.
- 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.
- 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.
- 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.
- Importance des conférences
- 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.
- 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.
- 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.
- 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.
- 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
- 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….
- 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
- 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.
- 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
- Rappel des besoins chiffres clés 1 diagramme système / containeur suffit ( en fonction de ce qui a présenter )