Le livre est composé de 7 parties, chacune contenant plusieurs chapitres (de 5 à 10). Passons brièvement en revue ces sections.
Introduction
Ici, tout est assez classique et standard. On y explique ce qu'est l'architecture propre et pourquoi elle est nécessaire. Les informations sont présentées sous forme de graphiques, par exemple, la croissance du nombre d'employés sur une certaine période et leur productivité (qui, comme vous vous en doutez, n'augmentait pas, car le sujet concerne la manière dont une mauvaise architecture peut fortement freiner et handicaper un projet).
Fondamentaux : paradigmes de programmation
Cette section commence par une brève histoire de la programmation, depuis Alan Turing et les premiers langages. Elle décrit la programmation structurée, la programmation orientée objet et la programmation fonctionnelle. Quelques mots sont également dits sur les tests. Des exemples de code sont donnés — ils sont en C.
Principes de conception
Il est ici question des modèles, ou plutôt des principes SOLID. En résumé, c'est l'essentiel de cette partie. Cinq chapitres distincts, chacun traitant d’un principe.
Principes d'organisation des composants
Cette section aborde le concept de composant. Un composant peut aussi être compris comme un module ou une autre unité de code indépendante. Des thèmes tels que la cohésion et le couplage des composants sont également analysés. Une attention particulière est accordée aux abstractions, à la conception descendante et ascendante. Les problèmes de dépendances cycliques entre composants sont également soulevés.
Architecture
On entre ici dans un domaine plus intéressant et plus pratique. Bien que le début de cette partie reste théorique, car il traite des phases de développement logiciel. Dès le début, l’auteur aborde un sujet crucial : la séparation des couches de code, qui est ensuite développée en détail dans les chapitres suivants. Selon l'auteur, le plus difficile dans cette séparation est de définir les frontières entre les composants, ce qui est difficile à contester. Quelques exemples et anecdotes réelles sont présentés. Le sujet des monolithes est également abordé. Enfin, après avoir évoqué de nombreux écueils, l’auteur introduit l’architecture propre. Selon lui, une architecture propre est une architecture en couches, en oignon, qui part des règles de la logique métier et se termine par les couches extérieures, comme les systèmes d'entrée/sortie et diverses interfaces. Le rôle des bases de données dans une telle architecture est brièvement discuté, ainsi que d'autres modèles comme les contrôleurs, les modèles et autres dans le cadre de l'architecture propre.
Détails
C'est ainsi que se nomme l'une des dernières sections. Elle se penche plus en détail sur le rôle des bases de données dans un projet et sur les interfaces web. Il est dit que le framework n’est qu’un outil, et qu’il ne faut pas s’attacher rigoureusement à l’architecture recommandée par tel ou tel framework. Le livre se termine par une annexe qui raconte à quoi ressemblaient les ordinateurs autrefois et comment il fallait travailler avec eux.
Conclusion
Commençons par énumérer les points positifs ou plutôt les particularités de ce livre. Il se lit facilement et rapidement, car il y a peu de code, mais en revanche, de nombreux diagrammes et schémas sont présents. Chaque chapitre est illustré dans un style uniforme et approprié. Du côté des inconvénients, ce livre s'adresse davantage aux développeurs débutants. Les novices devraient le lire en détail, tandis que les développeurs plus expérimentés peuvent le parcourir rapidement (cela ne prendra pas beaucoup de temps), mais pour les développeurs chevronnés et les architectes logiciels, ce livre risque de ne pas apporter grand-chose de nouveau.
