https://cegepmv.github.io/420-310/02-architecture-et-conception/index.htmlHugofr-frhttps://cegepmv.github.io/420-310/02-architecture-et-conception/notions-arch/notions-arch/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-310/02-architecture-et-conception/notions-arch/notions-arch/index.htmlLes architectures logicielles courantes comprennent les architectures monolithiques, les microservices, orientées événements, client-serveur et les architectures orientées services (SOA). Le choix dépend des besoins du projet, tels que la complexité, l’évolutivité et le temps de réponse souhaité. À travers ce module, nous passerons en revue quelques styles d’architecture logicielle (n-tiers, microservices, etc.) afin d’apprendre à les distinguer, à comprendre leurs forces et limites, et à reconnaître les contextes dans lesquels chacun excelle. Nous verrons aussi comment planifier une migration progressive (ex.: monolithe → monolithe modulaire → microservices), en minimisant les risques et en maximisant la valeur pour le projet et l’équipe.https://cegepmv.github.io/420-310/02-architecture-et-conception/notions-arch/api/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-310/02-architecture-et-conception/notions-arch/api/index.htmlAu sein d’une organisation N-tiers, l’API REST fait office de frontière entre les tiers : le frontend dialogue avec le backend au moyen d’URL, de verbes HTTP et de codes de statut, tandis que l’intérieur du backend reste structuré en MVC (contrôleur qui reçoit la requête, service qui porte la logique, repository qui accède aux données). En contexte monolithique, les couches de l’application communiquent surtout en interne par appels de méthodes, mais l’API REST demeure le contrat exposé vers l’extérieur (applications web ou mobiles, intégrations). On garde la même discipline MVC à l’intérieur du monolithe pour préserver la clarté du code et préparer d’éventuelles évolutions. En architecture microservices, chaque service expose sa propre API (souvent REST) et peut aussi échanger par événements ; chacun conserve son mini-MVC en interne. On conserve la même discipline MVC pour garder un code clair et préparer d’éventuelles évolutions. En architecture microservices, chaque service expose sa propre API (souvent REST) et peut aussi échanger par événements ; chacun conserve son mini-MVC en interne.https://cegepmv.github.io/420-310/02-architecture-et-conception/notions-arch/mvc/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-310/02-architecture-et-conception/notions-arch/mvc/index.htmlMVC signifie Model – View – Controller. C’est un patron architectural qui sépare les responsabilités d’une application : Modèle (Model) : représente les données et les règles métier du domaine (entités, validations, calculs). Vue (View) : s’occupe de la présentation pour l’utilisateur (page HTML, JSON en REST, PDF, etc.). Contrôleur (Controller) : reçoit la requête, valide les entrées, orchestre le traitement vers le modèle (via un service), puis choisit la vue/réponse. Idée clé : le contrôleur n’embarque pas la logique métier, la vue n’accède pas à la base de données, et le modèle est indépendant de la présentation.https://cegepmv.github.io/420-310/02-architecture-et-conception/patrons/patrons/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-310/02-architecture-et-conception/patrons/patrons/index.htmlLes patrons de conception GoF (Gang of Four) sont des solutions réutilisables à des problèmes récurrents de conception logicielle, classées par création, structure et comportement. Ils offrent un vocabulaire commun (noms, intentions) pour rendre le code plus clair, testable et évolutif. Les plus connus classés en patrons de création (comment créer les objets : Singleton, Factory Method, Abstract Factory, Builder, Prototype), patrons structurels (comment composer/relier les objets : Adapter, Decorator, Facade, Composite, Proxy, Bridge, Flyweight), et patrons comportementaux (comment les objets collaborent/échangent : Strategy, Observer, Command, Template Method, Iterator, Mediator, Memento, Visitor, Chain of Responsibility, Interpreter). Ils offrent un vocabulaire commun pour rendre le code plus clair, testable et évolutif.