Bracket Show épisode 24

Architecture, de « layered » à « clean » — Bracket Show, épisode 24

Dans cet épisode nous parlons de l’évolution de l’architecture logicielle à partir des modèles en couche (layered) juasqu’aux modèles plus modernes centrés sur le domaine.

 

Comment transformer une architecture de « layered » à « clean »?

Qu’est-ce que l’architecture?

Vue d’ensemble d’un système

Structure du système :

les différentes composantes
Les couches (layers)
Les relations entre les composantes

Complexité, consistance, cohérence, rigidité, fragilité, testable, maintenance

Architecture Clean

Couches bien délimitées : simple et compréhensible, flexible et solide, émergent, testable et maintenable

Qu’est-ce que l’on doit documenter dans l’architecture ? Ce n’est pas toujours ce que l’on croit.

Architecture traditionnelle :

Contraintes connues et fixes
Évolution limitée après la livraison initiale.
Ne peut pas être partiellement terminé.
Domaine de solution connu
Base immuable

Architecture Agile :

Contraintes ne sont pas toutes connues, elles sont en évolution continuelle
N’est jamais complètement terminée
Domaine de solution en évolution
Éventuellement une base immuable quand même

Architecture « Clean » centrée sur le domaine :

On a tendance à voir la base de données comme étant au centre de l’architecture

Transition vers le domaine au centre de notre modèle d’affaires

Utilisabilité VS Présentation

Plusieurs types d’architectures centrées sur le domaine :

Architecture hexagonale

Particularité : l’ordre des dépendances est important

Domaine au centre : les dépendances vont de l’extérieur vers l’intérieur

Architecture en oignon

Architecture « Clean »

Tout est développé sur les cas d’utilisation (Use cases)

Ordre du flow d’exécution
Ports d’entrée et de sortie

Différentes façons de représenter sensiblement les mêmes choses

Pourquoi une architecture centrée sur le domaine?

Pour

Se concentre sur l’essentiel
Moins de couplage sur les détails
Nécessaire pour la modélisation DDD

Contre

Changements plus difficiles
Demande plus de réflexion
Coût initial plus élevé

Modélisation en couches tout en maintenant le domaine au centre

Modèle N-tiers
Domain Driven Design

Persistance et Infrastructure
Sens du contrôle (Flow)
Commandes et requêtes
CQRS et Event Sourcing
Dénormalisation
Asynchronicité
Base d’écriture et base de lecture
Persistance du système

Organisation fonctionnelle
Screaming Architecture
Organisation technique
Éviter le couplage au framework
Perte des conventions et de la génération automatique
Bonded contexts
Contextes délimités

Conclusion

Leave a Reply

Your email address will not be published. Required fields are marked *