Java on MyBearIsYellow

Architecture hexagonale

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

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.

Clean Architecture expliquée simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

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.

Couplage fort vs faible

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

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.

Domain Driven Design (DDD)

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

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.

Le Pattern Abstract Factory expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

L’Abstract Factory va plus loin que la Factory simple : elle garantit qu’un ensemble d’objets liés entre eux (une famille) reste toujours cohérent, en regroupant plusieurs méthodes de création derrière une seule interface.

Le Pattern Adapter expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

Le Adapter Pattern permet à deux interfaces incompatibles de fonctionner ensemble, sans modifier ni l’une ni l’autre. Il s’intercale entre le code appelant et une librairie tierce pour traduire les appels d’un contrat vers un autre.

Le Pattern Builder expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

Le Builder Pattern sépare la construction d’un objet complexe en une série d’étapes chaînées, chacune configurant une partie de l’objet. Il évite les constructeurs à rallonge et rend le code de construction lisible, même avec de nombreux paramètres optionnels.

Le Pattern Decorator expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

Le Decorator Pattern permet d’ajouter dynamiquement des responsabilités à un objet, en l’enveloppant dans une ou plusieurs couches qui respectent la même interface. Une alternative à l’héritage quand les combinaisons de comportements se multiplient.

Le Pattern Dependency Injection expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

L’injection de dépendances (Dependency Injection) consiste à fournir à un objet ce dont il a besoin depuis l’extérieur, plutôt que de le laisser construire lui-même ses dépendances. Un principe simple qui rend le code testable et remplaçable.

Le Pattern Factory expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

Le Factory Pattern encapsule la logique de création d’un objet dans une méthode ou une classe dédiée, plutôt que de disperser des new conditionnels dans tout le code. Le client dépend d’une interface, jamais des classes concrètes créées derrière.

Le Pattern Observer expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

L’Observer Pattern définit une relation un-à-plusieurs : quand un objet change d’état, tous ses abonnés sont notifiés automatiquement, sans que l’émetteur ait besoin de connaître leur nature exacte. C’est le pattern derrière les event listeners et les systèmes pub/sub.

Le Pattern Repository expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

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.

Le Pattern Singleton expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

Le Singleton garantit qu’une classe n’a qu’une seule instance, accessible depuis n’importe où dans l’application. Pratique en apparence, mais c’est aussi l’un des patterns les plus critiqués : il introduit un état global qui rend le code difficile à tester et à faire évoluer.

Le Pattern Strategy expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

Le Strategy Pattern permet de faire varier un comportement indépendamment du code qui l’utilise. Au lieu d’empiler des if/else, on encapsule chaque variante dans sa propre classe, interchangeable à tout moment.

Séparation des responsabilités

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

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.

SOLID expliqué simplement

rajekevin@hotmail.fr (MyBearIsYellow) — Fri, 10 Jul 2026 00:00:00 +0000

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.