Architecture agile – Exemple – Deux styles d'architecte

View Github Repository Open presentation in a new window

arpinum

See all presentation from arpinum

Architecture agile – Exemple – Deux styles d'architecte

0 0

architecture-agile

On Github arpinum / architecture-agile

Architecture agile

arpinum.fr / @arpinum

Définition

Things that people perceive as hard to change Martin fowler

Exemple

Il faut prévoir le schéma de la base de données! Elle sera difficile à changer une fois en production!

Rendons le schéma changeable facilement

[Migration(98)]
public class IAdoria11_booking : Migration
{
    public override void Up()
    {
        Alter.Table("Booking").AddColumn("canceled").AsBoolean().NotNullable().WithDefaultValue(false);
    }

    public override void Down()
    {
        Delete.Column("canceled").FromTable("booking");
    }
}

Les grands principes

  • Permet de retarder les décisions
  • Minimise le couplage
  • Facile à changer
  • Testable !

Deux styles d'architecte

Architectus Reloadus

Architectus Oryzus

Proposition

  • DDD !
  • Architecture hexagonale
  • CQRS
  • Clean architecture
  • Et bien d'autres

Mettre le(s) métier(s) au coeur des préoccupations

«Stable dependencies principle»

  • Accepte parfaitement le TDD
  • La base de données n'existe pas

Encapsuler les cas d'utilisation dans des commandes

  • Permet de brancher facilement n'importe quoi (Web, Socket, Tests d'acceptation)
  • Peut permettre de déduire de meilleures interfaces graphiques
  • Éventuellement exécutable sur un autre serveur
  • Accepte parfaitement du TDD
  • La base de données n'existe pas

Mettre la lecture dans un autre modèle

  • Évite de brouiller le métier avec des considérations d'affichage
  • Permet de demander à la base ce qu'elle sait faire de mieux : recherche, indexation, full text, etc
  • Un peu plus difficile à tester :(
  • Devoir garder deux modèles en cohérence si on attaque la même source de données :(

Un service REST

  • Une certaine similarité de forme avec les concepts DDD
  • Accepte facilement éventuellement des tests de haut niveau
  • Accepte parfaitement le TDD
  • La base de données n'existe pas

Assemblage de l'ensemble au runtime

  • Tout est dans le code, pas de conventions plus ou moins tordues à se rappeler
  • C'est simple, pas simpliste

Et exposons ça dans une jolie application

Pour conclure

  • Avons-nous respecté les critères d'une bonne architecture ?
  • C'était pas si compliqué finalement
Are we really so naive as to think that the best way to write a complex system is to throw a bunch of components into a bag and shake it until it works? Uncle Bob