ALOM

🥙 Clean Archi et Archi Hexagonale

Salade, Tomates, Architecture Oignons

UBER

Problématiques :

Comment organiser le code ?

Comment ĂŞtre capable de changer de type de BDD ?

Minimiser le Blast-Radius đź’Łđź’Ą d'un changement

Séparer les responsabilités

L'architecture logicielle

  • Donner forme Ă  la construction d'un système
    • Division en composants
    • Arrangement des composants
    • Communication des composants
  • Le but :
    • Faciliter le dĂ©veloppement
    • Faciliter le dĂ©ploiement
    • Faciliter les opĂ©rations
    • Faciliter la maintenance

Les concepts des architectures logicielles

  • Separation of concerns
    • La BDD ne doit pas dĂ©pendre des IHM
    • Les règles mĂ©tier ne doivent pas dĂ©pendre de la BDD
    • Les règles mĂ©tier ne doivent pas dĂ©pendre des IHM

đź‘® S.O.L.I.D principles

  • S : Single Responsability
  • Une classe doit avoir une seule responsabilitĂ©
  • O : Open/Closed
  • Ouvert Ă  l'extension, mais fermĂ© Ă  la modification
  • L : Liskov Substitution
  • Pouvoir utiliser un sous-type
  • I : Interface Segregation
  • PrĂ©senter plusieurs interfaces spĂ©cifiques
  • D : Dependency Inversion
  • DĂ©pendre d'abstractions, et non d'implĂ©mentations

Domain-Driven Design (DDD)

Les archis modernes prennent souvent racine dans les concepts de DDD.

  • Domaine MĂ©tier : Le cĹ“ur de l'application est la logique mĂ©tier.
  • Ubiquitous Language : Un langage commun entre les dĂ©veloppeurs et les experts mĂ©tier.
  • Entities et Value Objects : Des objets qui reprĂ©sentent les concepts fondamentaux du mĂ©tier.

L'architecture n-tier (années 90)

Séparation physique entre les programmes et les BDD, entre les clients et les serveurs

L'architecture n-tier avec Spring

La vision "classique"

L'architecture Hexagonale (ports et adapters)

Conceptualisé par Alistair Cockburn en 2005

La Onion Architecture

Conceptualisé par Jeffrey Palermo en 2008

La Clean Architecture

Conceptualisé par Robert C. Martin en 2012

Les éléments communs (et importants)

  • SĂ©parer la logique mĂ©tier des dĂ©tails techniques
  • IndĂ©pendance d'un framework
  • TestabilitĂ©
  • IndĂ©pendance de la partie UI
  • IndĂ©pendance de la partie BDD

TP

Critères de notation