Noms, structure et code vers lequel on peut revenir
Les noms
Un nom dit ce que la chose fait dans le langage du domaine, pas comment elle est implémentée. Un nom qui nécessite un commentaire pour être compris est un mauvais nom.
Soyez cohérent : le même terme pour le même concept dans tout le système, y compris dans la base de données et l'interface. Deux noms pour une chose sont une source constante de bugs.
La structure
Organisez par domaine commercial et non par type de fichier. Un dossier « commandes » contenant tout ce qui concerne les commandes est plus facile à naviguer que des dossiers séparés par couche.
Maintenez les frontières : un module atteint un autre via une interface définie, pas via ses parties internes. Les frontières maintenues à l'intérieur d'un système sont ce qui permet de le diviser plus tard si nécessaire.
La simplicité
Préférez le code ennuyeux. Une abstraction créée avant qu'il y ait trois vrais cas est presque toujours mauvaise, et plus difficile à supprimer qu'à ajouter.
Pour aller plus loin
Quand le code est difficile à tester, c'est presque toujours le signe d'une dépendance mélangée à la logique. Au lieu d'ajouter des simulations, injectez la dépendance — le test se simplifie et la structure s'améliore ensemble, et c'est l'un des signes les plus fiables d'un design qui nécessite une correction.