conception logicielle, des bases à l'architecture

Objectifs du module

À la fin de ce module, vous serez capable de :

Définir ce qu'est la conception et la distinguer du codage et de l'architecture.
Appliquer les principes SOLID et reconnaître les situations où ils sont violés.
Utiliser les design patterns fondamentaux pour résoudre des problèmes récurrents.
Modéliser un domaine avec les concepts du Domain-Driven Design.
Choisir un style architectural adapté au contexte (monolithe, modulaire, microservices).
Tracer le chemin de la décision de conception jusqu'à la décision d'architecture.

Partie 1 — La conception, les bases

1.1 Qu'est-ce que la conception logicielle ?

La conception (ou software design) est l'activité qui consiste à définir comment un système va être structuré avant (et pendant) l'implémentation. Elle répond à la question : « comment le code va-t-il être organisé pour que le système soit compréhensible, évolutif et testable ? »

flowchart LR
  Besoin["Besoin métier"] --> Conception["Conception — structure du code"]
  Conception --> Implem["Implémentation"]
  Implem --> Test["Tests automatisés"]
  Test -->|"feedback"| Conception

La conception n'est pas un livrable figé produit une fois avant de coder. C'est une activité itérative, nourrie par les retours des tests et de la pratique.

Niveau	Question centrale	Exemple
Conception	Comment organiser mes classes et modules ?	Découper un service en couches
Architecture	Comment organiser mes composants et systèmes ?	Choisir entre monolithe et microservices
Codage	Comment écrire une fonction correctement ?	Nommer une variable, écrire un test

1.2 Les principes SOLID

Les cinq principes SOLID forment la base de la conception orientée objet de qualité.

Sigle	Principe	Violation typique
S	Single Responsibility — une classe = une raison de changer	Classe `UserService` qui gère l'auth, l'envoi d'email et la persistence
O	Open/Closed — ouvert à l'extension, fermé à la modification	Ajout d'un `if` à chaque nouveau type dans une méthode
L	Liskov Substitution — une sous-classe remplace sa classe parente sans surprises	`Duck extends Bird` mais `Duck.fly()` lève une exception
I	Interface Segregation — interfaces petites et ciblées	Interface `IWorker` avec `work()` et `eat()` imposée à un robot
D	Dependency Inversion — dépendre d'abstractions, pas d'implémentations	`OrderService` instancie `new MySQLOrderRepository()` en dur

flowchart LR
  OC["Open/Closed : stratégie ou polymorphisme"] --> DIP["DIP : injection de dépendance"]
  SRP["SRP : responsabilités séparées"] --> OC
  ISP["ISP : interfaces ciblées"] --> DIP
  LSP["LSP : contrat respecté"] --> OC