Le problème de départ

On part d'une liste de fonctionnalités (un backlog, un cahier des charges, des user stories). Cette liste décrit le quoi. La conception, elle, répond au comment.

flowchart LR
	F["Fonctionnalités<br>— ce que le système doit faire"]
	C["Conception<br>— la structure du système"]
	F -->|"analyse, décomposition, décisions"| C

Les fonctionnalités définissent les responsabilités, et les responsabilités définissent la conception.

Exemple fil rouge : application de gestion de tâches

Liste de fonctionnalités initiale

- Créer une tâche
- Modifier une tâche
- Supprimer une tâche
- Marquer une tâche comme terminée
- Attribuer une date d'échéance
- Filtrer les tâches par statut
- Authentification utilisateur
- Authentification admin
- créer un compte
- Partage de tâches entre utilisateurs
- gestion des permissions
- Notifications de rappel

À ce stade, on est dans le fonctionnel pur. On sait ce que l'application fait, pas encore comment elle est construite.

Étape 1 — Regrouper par domaines métier

La première décision de conception consiste à identifier les responsabilités et les regrouper en modules logiques.

Module Fonctionnalités incluses
Task Créer, modifier, supprimer, compléter, échéance, filtrer
User Authentification, comptes, droits
Sharing Partage entre utilisateurs, permissions
Notification Rappels, planification d'envoi 
flowchart LR
	subgraph modules["Modules identifiés"]
		TM["Task Module"]
		UM["User Module"]
		SM["Sharing Module"]
		NM["Notification Module"]
	end

Premier choix de conception : découpage modulaire. Chaque module correspond à un domaine métier cohérent. Les fonctionnalités qui changent pour les mêmes raisons sont regroupées ensemble (SRP à l'échelle du module).

Étape 2 — Identifier les entités métier

On se demande : quelles sont les "choses" importantes que le système manipule ?

Task
User
Reminder
SharePermission