MFormations
Modern Information Systems Engineering

Chapitre 21

21-Livres

> Résumés et fiches de lecture des ouvrages fondamentaux pour l'architecte SI.

Cours : Résumés de Livres d'Architecture SI

Introduction

Cette section résume les ouvrages fondamentaux pour l'architecte système d'information. Les résumés sont structurés pour fournir une vue d'ensemble opérationnelle. Pour une maîtrise approfondie, la lecture complète des ouvrages reste indispensable.

1. Domain-Driven Design — Eric Evans (2003)

Informations

  • Titre : Domain-Driven Design: Tackling Complexity in the Heart of Software
  • Auteur : Eric Evans
  • Éditeur : Addison-Wesley
  • Pages : 560
  • ISBN : 978-0321125217

Contexte du livre

Publié en 2003, ce livre a révolutionné la façon de concevoir des logiciels complexes. Il propose une approche centrée sur le domaine métier, où la modélisation et le code sont intimement liés.

Partie I : Mettre le domaine en avant

  • Ch1-3 : Pourquoi le DDD ? Le modèle est le cœur du logiciel
  • Ch4 : Ubiquitous Language — langage commun entre experts métier et développeurs
  • Ch5 : Modélisation itérative — le modèle évolue avec la compréhension du domaine

Partie II : Building blocks du DDD

  • Entités : objets avec une identité unique (une personne, une commande)
  • Value Objects : objets sans identité, définis par leurs attributs (une adresse, un montant)
  • Services : opérations du domaine qui n'appartiennent pas naturellement à une entité
  • Modules : organisation du modèle en ensembles cohérents
  • Aggregates : clusters d'objets traités comme une unité, avec une racine (aggregate root)
  • Factories : construction d'objets complexes
  • Repositories : accès aux objets persistés

Partie III : Restructuration pour mieux comprendre

  • Ch9 : Spécifications — prédicats réutilisables pour la validation
  • Ch10 : Modélisation souple — refactoring vers des modèles expressifs
  • Ch11 : Découvrir des concepts cachés
  • Ch12 : Modèles de design flexibles

Partie IV : Conception stratégique

  • Ch13 : Bounded Context — délimitation explicite d'un modèle
  • Ch14 : Context Mapping — relations entre contextes
  • Ch15 : Distillation — séparer le cœur du domaine du générique
  • Ch16 : Large-Scale Structures — patterns pour organiser à grande échelle

Concepts clés à retenir

  1. Ubiquitous Language : vocabulaire partagé, évolutif, sans jargon technique
  2. Bounded Context : frontière explicite où chaque terme a un sens précis
  3. Aggregate : cohérence transactionnelle, invariants protégés par la racine
  4. Context Map : vision d'ensemble des relations entre contextes
  5. Core Domain : ce qui rend le système unique et compétitif

Impact

Le DDD a influencé tous les courants modernes : microservices, Event Sourcing, CQRS. Il est devenu un standard pour les systèmes complexes.

2. Implementing Domain-Driven Design — Vaughn Vernon (2013)

Informations

  • Titre : Implementing Domain-Driven Design
  • Auteur : Vaughn Vernon
  • Éditeur : Addison-Wesley
  • Pages : 656
  • ISBN : 978-0321834577

Présentation

Complément pratique du livre d'Evans, Vernon montre comment implémenter le DDD en Java/C# avec des exemples concrets.

Partie I : Fondamentaux

  • Architecture en couches, hexagonal, CQRS
  • Entités, Value Objects, Services, Domain Events
  • Aggregates : règles de conception, taille, performance

Partie II : Stratégie

  • Bounded Context implementation
  • Context Mapping patterns
  • Intégration entre contextes

Partie III : Implémentation

  • Event Storming et modelling workshops
  • Domain Events implémentation
  • Event Sourcing et CQRS

Exemple : Aggregate Commande

public class Commande extends AggregateRoot {
    private CommandeId id;
    private ClientId clientId;
    private List<LigneCommande> lignes;
    private Money total;
    private CommandeStatus status;
    
    public Commande(ClientId clientId) {
        this.id = CommandeId.generate();
        this.clientId = clientId;
        this.lignes = new ArrayList<>();
        this.status = CommandeStatus.CREEE;
        this.total = Money.ZERO;
        this.addDomainEvent(new CommandeCreee(id, clientId));
    }
    
    public void ajouterProduit(ProductId produitId, int quantite) {
        // Règle : max 100 lignes
        if (lignes.size() >= 100) {
            throw new IllegalStateException("Maximum 100 lignes par commande");
        }
        LigneCommande ligne = new LigneCommande(produitId, quantite);
        lignes.add(ligne);
        total = total.add(ligne.sousTotal());
    }
}

3. Software Architecture in Practice — Bass, Clements, Kazman (4e éd., 2021)

Informations

  • Titre : Software Architecture in Practice, 4th Ed.
  • Auteurs : Len Bass, Paul Clements, Rick Kazman
  • Éditeur : Addison-Wesley
  • Pages : 528
  • ISBN : 978-0136886099

Présentation

Le livre de référence sur l'architecture logicielle, utilisé dans les cursus universitaires et pour la certification iSAQB.

Partie I : Introduction

  • Ch1 : Qu'est-ce que l'architecture ?
  • Ch2 : Pourquoi l'architecture est importante
  • Ch3 : Le contexte de l'architecture (technique, projet, business)

Partie II : Attributs de qualité

  • Ch4 : Comprendre les attributs de qualité
  • Ch5 : Disponibilité (availability)
  • Ch6 : Déployabilité
  • Ch7 : Énergie (green IT)
  • Ch8 : Intéropérabilité
  • Ch9 : Maintenabilité
  • Ch10 : Performance
  • Ch11 : Sécurité
  • Ch12 : Testabilité
  • Ch13 : Facilité d'usage

Partie III : Solutions architecturales

  • Ch14 : Tactiques architecturales (patterns pour chaque attribut de qualité)
  • Ch15 : Patrons architecturaux (layers, pipes-and-filters, microservices, etc.)
  • Ch16 : Qualité et modèles de qualité

Partie IV : Principes d'analyse

  • Ch17 : Architecture analysis (ATAM, CBAM)
  • Ch18 : Architecture documentation

Partie V : En pratique

  • Ch19 : Architecture en contexte agile
  • Ch20 : Exemples : systèmes IoT, cloud-native, AI

Méthode ATAM

Architecture Tradeoff Analysis Method — méthode d'évaluation d'architecture :

  1. Presentation : architecture, business drivers
  2. Analysis : identifier les scénarios de qualité
  3. Tradeoffs : analyser les points de tension
  4. Reporting : documenter les risques et compromis

Tactiques par attribut de qualité

  • Performance : ressource demand, resource management, resource arbitration
  • Disponibilité : fault detection, fault recovery, fault prevention
  • Sécurité : authenticate, authorize, audit, encrypt
  • Testabilité : controllability, observability

4. Just Enough Software Architecture — George Fairbanks (2010)

Informations

  • Titre : Just Enough Software Architecture: A Risk-Driven Approach
  • Auteur : George Fairbanks
  • Éditeur : Marshall & Brainerd
  • Pages : 376
  • ISBN : 978-0978160117

Présentation

Ce livre plaide pour une approche pragmatique : ne modéliser que ce qui est nécessaire, en fonction des risques.

Approche Risk-Driven

  • Principe : l'architecture doit réduire les risques
  • Question clé : "Qu'est-ce qui pourrait mal tourner ?"
  • Méthode : investir dans l'architecture proportionnellement au risque

Risques architecturaux typiques

  1. Fonctionnalité manquante (incomplétude)
  2. Mauvaise performance
  3. Indisponibilité
  4. Problèmes de sécurité
  5. Difficulté de maintenance
  6. Verrouillage technologique

Niveaux d'investissement architectural

  1. Inexistant : pas de modélisation (petits projets, prototypes)
  2. Minimal : quelques diagrammes informels
  3. Standard : documentation structurée (C4, ADR)
  4. Rigoureux : modèles formels, vérification (systèmes critiques)

Concepts clés

  • Architecture as a hypothesis : l'architecture est une hypothèse qui doit être validée
  • Model-driven vs sketch-driven : ne pas confondre modèles formels et croquis
  • Architecture decisions : capturer le pourquoi, pas seulement le quoi
  • Risk storming : atelier d'identification des risques

Relation avec l'agilité

  • L'agilité n'est pas une excuse pour ne pas faire d'architecture
  • L'architecture émerge, mais avec une direction intentionnelle
  • Les décisions tardives sont bonnes seulement si elles sont réversibles

5. Documenting Software Architectures — Clements et al. (2e éd., 2010)

Informations

  • Titre : Documenting Software Architectures: Views and Beyond, 2nd Ed.
  • Auteurs : Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford
  • Éditeur : Addison-Wesley
  • Pages : 560
  • ISBN : 978-0321552686

Présentation

Guide complet pour documenter l'architecture en utilisant l'approche "Views and Beyond".

L'approche Views and Beyond

  • View : représentation d'un ensemble d'éléments et de relations
  • Au moins 3 vues : module, component-and-connector, allocation
  • Beyond : information au-delà des vues (rationale, variabilité, standards)

Catégories de vues

Vues Module :

  • Decomposition view (modules, sous-modules)
  • Uses view (dépendances)
  • Generalization view (héritage)
  • Layered view (couches)

Vues Component-and-Connector :

  • Pipe-and-filter view
  • Shared-data view
  • Publish-subscribe view
  • Client-server view
  • Concurrency view

Vues Allocation :

  • Deployment view (matériel)
  • Implementation view (code → modules)
  • Work assignment view (équipes)

Contenu d'un document d'architecture

  1. Documentation roadmap : guide du lecteur
  2. Architecture overview : résumé pour tous
  3. View collection : les vues détaillées
  4. Architecture rationale : pourquoi ces choix
  5. Directory : glossaire, index

Qualité d'une documentation

  • Correcte : conforme à la réalité implémentée
  • Complète : suffisante pour le public cible
  • Accessible : facile à naviguer, langage adapté
  • À jour : maintenue avec l'implémentation
  • Vérifiable : peut être validée

Évaluation avec la méthode DASA

  1. D : Déterminer le public
  2. A : Analyser les besoins d'information
  3. S : Sélectionner les vues appropriées
  4. A : Ajouter de l'information au-delà des vues

6. Clean Architecture — Robert C. Martin (2017)

Fiche de lecture

  • Pages : 432
  • ISBN : 978-0134494166

Principes fondamentaux

  1. Indépendance framework : le framework est un outil, pas le cadre
  2. Testabilité : l'architecture doit rendre le code testable
  3. Indépendance UI : l'interface peut changer sans impacter le métier
  4. Indépendance DB : la base de données est un détail
  5. Indépendance externe : les agents externes sont interchangeables

The Dependency Rule

Les dépendances dans le code source ne peuvent pointer que vers l'intérieur :

  • Frameworks/Drivers (niveau externe)
  • Interface Adapters
  • Application Business Rules (Use Cases)
  • Enterprise Business Rules (Entities)

Screaming Architecture

L'architecture doit "crier" le domaine métier, pas la technologie. Un système de santé doit d'abord ressembler à un système de santé, pas à Spring ou ASP.NET.

7. Building Microservices — Sam Newman (2e éd., 2021)

Fiche de lecture

  • Pages : 614
  • ISBN : 978-1492034025

Pourquoi microservices ?

  • Couplage lâche, cohésion forte
  • Déploiement indépendant
  • Équipes autonomes
  • Choix technologiques par service

Modélisation

  • Découpage par bounded context
  • Taille : "suffisamment petit pour que l'équipe comprenne, suffisamment grand pour que ça ait du sens"
  • APIs : REST, gRPC, GraphQL

Intégration

  • Orchestration vs chorégraphie
  • Event-driven collaboration
  • Sagas pour les transactions distribuées
  • API Gateway pattern

8. Patterns of Enterprise Application Architecture — Martin Fowler (2002)

Fiche de lecture

  • Pages : 560
  • ISBN : 978-0321127426

Patterns clés

  • Layered Architecture : presentation, domain, data source
  • Domain Model vs Transaction Script
  • Table Module, Active Record, Data Mapper
  • Identity Map, Unit of Work, Lazy Load
  • Repository, Query Object, Specification

9. Enterprise Integration Patterns — Hohpe & Woolf (2003)

Fiche de lecture

  • Pages : 736
  • ISBN : 978-0321200686

Patterns de messaging

  • Message Channel, Pipe, Filter
  • Message Router, Splitter, Aggregator
  • Message Translator
  • Message Endpoint
  • Publisher-Subscriber

10. Designing Data-Intensive Applications — Martin Kleppmann (2017)

Fiche de lecture

  • Pages : 616
  • ISBN : 978-1449373320

Partie I : Fondements

  • Ch1 : Fiabilité, Scalabilité, Maintenabilité
  • Ch2 : Modèles de données et langages de requêtage
  • Ch3 : Stockage et récupération (LSM-Trees vs B-Trees)
  • Ch4 : Encodage et évolution des schémas

Partie II : Données distribuées

  • Ch5 : Réplication (leader/follower, multi-leader, quorum)
  • Ch6 : Partitionnement (sharding, hash, range)
  • Ch7 : Transactions (ACID, BASE, isolation levels)
  • Ch8 : Problèmes des systèmes distribués
  • Ch9 : Consistance et consensus (CAP, Paxos, Raft)

Partie III : Systèmes dérivés

  • Ch10 : Traitement par lots (MapReduce, Spark)
  • Ch11 : Traitement de flux (Kafka, Flink)
  • Ch12 : L'avenir des systèmes de données

Plan de lecture recommandé

Pour débuter (niveau junior)

  1. Software Architecture in Practice (chapitres 1-3)
  2. Clean Architecture
  3. Just Enough Software Architecture

Pour approfondir (niveau confirmé)

  1. Domain-Driven Design (Evans)
  2. Implementing DDD (Vernon)
  3. Documenting Software Architectures

Pour maîtriser (niveau senior)

  1. Designing Data-Intensive Applications
  2. Building Microservices
  3. Enterprise Integration Patterns
  4. Patterns of Enterprise Application Architecture
PrécédentChapitre 20 — 20-RessourcesSuivantChapitre 22 — 22-Interviews