00 - Introduction : pourquoi on structure le code autour du métier
Ce que tu vas apprendre
- Pourquoi penser "domaine métier" avant de penser "code"
- Ce que cette serie d'articles couvre
- Comment naviguer dans le cours
Prerequisites
Aucun. C'est le point de depart.
Le problème
Quand on commence a coder, on pense en termes de features : "je dois faire un formulaire", "je dois afficher une liste", "je dois appeler une API". On empile du code, ca marche, on livre.
Puis un jour, quelqu'un demande : "dans quel état est cette Place ?". Et la, personne ne sait répondre. L'état est disperse entre le frontend, une base de donnees, un cache local, et la mémoire d'un développeur qui a quitte l'équipe.
Ce problème n'est pas un bug. C'est une absence de structure. On a construit des features sans avoir défini ce qu'on construisait réellement.
La solution : penser "domaine" d'abord
Un domaine métier (on verra ca en détail dans l'article suivant) c'est la réalité de ton application, indépendamment du code. C'est la réponse a la question : "de quoi parle ce logiciel ?".
Quand tu structures ton code autour du domaine :
- Tu sais nommer les choses correctement
- Tu sais quels états existent et lesquels sont autorises
- Tu sais ou trouver la vérité sur l'état d'une entité
- Tu sais ce qui doit toujours etre vrai (les invariants)
- Tu peux ajouter ou supprimer des features sans casser le reste
Quand tu ne le fais pas :
- L'état est disperse partout
- Les regles métier sont dupliquees dans 5 fichiers
- Personne ne sait si un objet est "pret" ou "en cours"
- Chaque nouvelle feature ajoute de la dette technique
C'est un problème que je rencontre souvent en tant que développeur fullstack, et c'est aussi un sujet qu'on aborde sur paltemps.fr quand on parle d'architecture logicielle.
Ce que couvre cette serie
Ce cours est une progression. Chaque article s'appuie sur le précédent.
| # | Article | Tu apprendras... |
|---|---|---|
| 01 | Le domaine métier | Ce qu'est un domaine, ses composants, ses frontieres |
| 02 | Entités et identité | La différence entre une entité et un value object |
| 03 | Cycle de vie | Comment une entité evolue à travers des états |
| 04 | State Machine | Comment formaliser ces états dans une machine a états |
| 05 | Transitions et guards | Les regles qui controlent le passage d'un état a l'autre |
| 06 | Source de vérité | Pourquoi l'état doit vivre a un seul endroit |
| 07 | Invariants | Ce qui doit toujours etre vrai, quoi qu'il arrive |
| 08 | Idempotence | Comment rendre les opérations repetables sans danger |
| 09 | Dette technique | Ce qui arrive quand on ignore tout ca |
| 10 | Features vs Domaine | Comment découper les features autour du lifecycle |
| 11 | Glossaire | Tous les termes techniques, définis et illustres |
Comment lire ce cours
Lis les articles dans l'ordre. Chaque article definit les termes qu'il utilise, mais il s'appuie sur les concepts des articles précédents.
Les exemples utilisent le domaine Place (un lieu touristique qui traverse un cycle de vie : création, enrichissement, traitement d'images, publication). C'est un cas réel, pas un exercice theorique.
Résumé
- Structurer le code autour du métier, c'est définir "de quoi on parle" avant "comment on code"
- Sans cette structure, l'état est disperse, les regles sont dupliquees, et la dette technique s'accumule
- Ce cours couvre tout ce qu'il faut savoir : domaine, entités, lifecycle, state machines, et plus
- Chaque article est autonome mais s'inscrit dans une progression
Article suivant : 01 - Le domaine métier : la fondation de tout