Architecture et placement
Un bon modèle pourrit quand même si personne ne sait où va le code. Cette partie répond à trois questions, dans cet ordre.
| Axe | La question | Thèmes |
|---|---|---|
| Structure | Où vit le code, et comment il tient ensemble ? | Le sens des dépendances (LAY), le dossier de chaque fichier (PLC), le nom de chaque fichier et de chaque type (NAM), l’assemblage des pièces (WIR) |
| Flux | Que fait une opération ? | Une command modifie des aggregates, une query lit des views (UC), l’API HTTP les appelle (API), la base garde ce que le modèle décide (PER) |
| Preuve | Comment le code est-il testé ? | Sur une infrastructure réelle, depuis les vrais modules, à côté de ce que les tests prouvent (TST) |
L’architecture de référence donne l’organisation que toutes les règles supposent. Les thèmes de cette partie donnent les règles qui la fondent.
En revue de code
- Le domaine n’importe-t-il aucune technologie, et chaque import va-t-il vers l’intérieur ? (LAY-01, LAY-02)
- Chaque fichier est-il dans le dossier de son concept et de sa technologie, et son nom dit-il son rôle ? (PLC-04, PLC-07, NAM-01)
- Le module du bounded context est-il le seul à lier un port à son implémentation ? (WIR-01)
- Le use case reste-t-il mince, et une query lit-elle une view sans charger d’aggregate ? (UC-04, UC-08)
- Les tests tournent-ils sur la vraie infrastructure, depuis les vrais modules ? (TST-01, TST-03)
Thèmes
LAY4 règlesCouches et dépendancesUn domaine isolé, des dépendances tournées vers l’intérieur, sans cycle, et le contrat public pour seule porte.Voir les règles →PLC12 règlesCe qui va oùUne place évidente pour chaque morceau de code, un module par concept.Voir les règles →NAM8 règlesNommage et rôles de fichiersUn fichier dit son rôle dans son nom, un dossier son concept.Voir les règles →WIR11 règlesWiringL’assemblage en périphérie, sans framework dans le modèle.Voir les règles →UC10 règlesUse casesUne opération par use case, mince, sécurisée, une command ou une query.Voir les règles →API2 règlesAPI HTTPDes routes et des représentations qui n’exposent pas le modèle.Voir les règles →PER12 règlesPersistanceSchémas, mappers et transactions tenus hors du modèle.Voir les règles →TST6 règlesTestsDes tests placés selon ce qu’ils prouvent, sur une infrastructure réelle.Voir les règles →