https://www.mybearisyellow.me/tags/architecture/ Recent content in Architecture on MyBearIsYellow Hugo fr-FR rajekevin@hotmail.fr (MyBearIsYellow) rajekevin@hotmail.fr (MyBearIsYellow) © 2026 MyBearIsYellow Fri, 10 Jul 2026 00:00:00 +0000 https://www.mybearisyellow.me/architecture-logicielle/architecture-hexagonale/ Fri, 10 Jul 2026 00:00:00 +0000rajekevin@hotmail.fr (MyBearIsYellow) https://www.mybearisyellow.me/architecture-logicielle/architecture-hexagonale/ L’architecture hexagonale (Ports & Adapters) place le métier au centre et le connecte au monde extérieur via des ports — des interfaces définies par le métier — implémentés par des adaptateurs interchangeables. La base de données, l’API REST ou la CLI ne sont que des détails branchés sur ces ports. https://www.mybearisyellow.me/architecture-logicielle/clean-architecture-expliquee-simplement/ Fri, 10 Jul 2026 00:00:00 +0000rajekevin@hotmail.fr (MyBearIsYellow) https://www.mybearisyellow.me/architecture-logicielle/clean-architecture-expliquee-simplement/ La Clean Architecture organise le code en cercles concentriques : le métier au centre, les détails techniques (base de données, framework, UI) à l’extérieur. La règle est simple — les dépendances ne pointent jamais vers l’extérieur. https://www.mybearisyellow.me/architecture-logicielle/couplage-fort-vs-faible/ Fri, 10 Jul 2026 00:00:00 +0000rajekevin@hotmail.fr (MyBearIsYellow) https://www.mybearisyellow.me/architecture-logicielle/couplage-fort-vs-faible/ Le couplage mesure à quel point un composant dépend d’un autre. Un couplage fort rend le système fragile et difficile à faire évoluer ; un couplage faible, obtenu via des interfaces et l’injection de dépendance, permet de changer une implémentation sans toucher au code qui l’utilise. https://www.mybearisyellow.me/architecture-logicielle/domain-driven-design-ddd/ Fri, 10 Jul 2026 00:00:00 +0000rajekevin@hotmail.fr (MyBearIsYellow) https://www.mybearisyellow.me/architecture-logicielle/domain-driven-design-ddd/ Le Domain Driven Design (DDD) est autant une démarche de modélisation métier qu’une technique de code. Il propose un vocabulaire partagé avec les experts métier, des frontières explicites entre sous-domaines (bounded context), et des règles précises pour modéliser entités, value objects et agrégats. https://www.mybearisyellow.me/design-patterns/repository/ Fri, 10 Jul 2026 00:00:00 +0000rajekevin@hotmail.fr (MyBearIsYellow) https://www.mybearisyellow.me/design-patterns/repository/ Le Repository Pattern cache les détails de stockage (SQL, ORM, API externe) derrière une interface orientée métier. Le domaine manipule des objets, pas des requêtes — l’implémentation concrète du stockage reste un détail interchangeable. https://www.mybearisyellow.me/architecture-logicielle/quest-ce-quune-architecture-logicielle/ Fri, 10 Jul 2026 00:00:00 +0000rajekevin@hotmail.fr (MyBearIsYellow) https://www.mybearisyellow.me/architecture-logicielle/quest-ce-quune-architecture-logicielle/ L’architecture logicielle, ce n’est pas un diagramme ou un framework : c’est l’ensemble des décisions structurelles qui coûtent cher à changer une fois prises. Comprendre cette notion, c’est apprendre à distinguer ce qui est difficile à défaire de ce qui ne l’est pas. https://www.mybearisyellow.me/architecture-logicielle/separation-des-responsabilites/ Fri, 10 Jul 2026 00:00:00 +0000rajekevin@hotmail.fr (MyBearIsYellow) https://www.mybearisyellow.me/architecture-logicielle/separation-des-responsabilites/ Séparer les responsabilités, ce n’est pas seulement écrire des petites classes : c’est isoler chaque raison de changer dans sa propre unité, que ce soit une classe, un module ou une couche entière du système. Bien fait, un changement métier ne touche qu’un seul endroit du code. https://www.mybearisyellow.me/architecture-logicielle/solid-explique-simplement/ Fri, 10 Jul 2026 00:00:00 +0000rajekevin@hotmail.fr (MyBearIsYellow) https://www.mybearisyellow.me/architecture-logicielle/solid-explique-simplement/ SOLID est un acronyme regroupant cinq principes de conception orientée objet formulés par Robert C. Martin : Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation et Dependency Inversion. Ensemble, ils visent un seul objectif : pouvoir faire évoluer le code sans le casser.