13
UXDA : une architecture logicielle pilotée par l'eXpérience Utilisateur Human Talks Lyon – Octobre 2013 – Hébergé par La Cordée Clément Bouillier - @clem_bouillier

20131008 - uxda - human talk

Embed Size (px)

DESCRIPTION

Support Human Tals Lyon 8 octobre 2013 UXDA : une architecture logicielle pilotée par l'eXperience Utilisateur

Citation preview

Page 1: 20131008 - uxda - human talk

UXDA : une architecture logicielle pilotée par

l'eXpérience UtilisateurHuman Talks Lyon – Octobre 2013 – Hébergé par La Cordée

Clément Bouillier - @clem_bouillier

Page 2: 20131008 - uxda - human talk

Qui suis-je ?

Architecte/chef de projet/consultant mais avant tout ARTISAN DEVELOPPEUR

> Twitter : @clem_bouillier

Membre actif des groupes suivants> DevLyon : groupe de développeurs partageant une vision de

l’informatique créant de la valeur http://devlyon.fr> MUG Lyon : groupe de passionnés de technologies en

environnement Microsoft sur Lyon> Fier d’être développeur : groupe visant à promouvoir le métier

de développeur en France http://fierdetredeveloppeur.org/

Page 3: 20131008 - uxda - human talk

10 minutes pour aller plus loin

1. Limites des applications CRUD et d’une architecture 3-tiers « type »

2. Des applications plus proches des utilisateurs avec la démarche UX

3. Des pistes pour une architecture « UX friendly » (UXDA ?)

Page 4: 20131008 - uxda - human talk

Applications CRUD

Create

Read

Update

Delete

CRUD

INSERT

SELECT

UPDATE

DELETE

SGBDR

=> Un objet cible => Une table

Je vais demander à l’utilisateur quels concepts il manipule, et pif paf pouf, je lui fais table pour et

une IHM CRUD associée

Page 5: 20131008 - uxda - human talk

Applications CRUD

Create

Read

Update

Delete

CRUD

WTF ?!? Pourquoi dois-je m’adapter à un outil qui était

sensé m’aider ?L’intention utilisateur est perdue

via des applications CRUD

Une application métier n’est-elle pas plus qu’un éditeur amélioré de base de données ?

Page 6: 20131008 - uxda - human talk

Architecture en couche type

Présentation/IHM

Objets métier

Services métier

Accès aux données

CRUD sur les objets métier

Objets métier POCO/POJO/POPO = DTO => utilisé entre les couches présentation et métier

=> ne refléte pas les intentions utilisateurs=> anémiques (peu d’encapsulation)=> bien souvent construit à partir de la base de

données=> voire complètement dépendant de la BDD si

pattern Active RecordServices métier = Transaction Script, ayant la fâcheuse tendance à enfler

=> peu de séparation des responsabilités, de cohérence entre méthodes…=> une dépendance très forte sur la base de données

Page 7: 20131008 - uxda - human talk

Démarche UX (User eXperience) et agilitéUX est une démarche de conception visant à se concentrer sur les usages de l’utilisateur

=> modéliser les usages plus que les concepts

Des pratiques agiles s’inspirent de l’UX => exemple : format User Voice avec Personas

pour décrire une User Story=> pourquoi l’utilisateur utilise l’application ?

Pourquoi ne pas fonder notre architecture sur toutes ces informations ?

Page 8: 20131008 - uxda - human talk

L’architecture en oignon (Onion Architecture)

Page 9: 20131008 - uxda - human talk

UXDA : une architecture « UX friendly »1) Introspection des usages des utilisateurs

=> appropriation de l’Ubiquituous Language (DDD)

2) Une architecture en oignon représentant le métier=> Pattern Command pour chaque cas d’usage (User Story) = lien

entre les couches présentation et métier + périmètre de transaction=> S’applique à un objet Domain Model non anémique = encapsule

la cohérence des données internes=> Un Domain Event est levé lorsque => découplage de la

persistance

Page 10: 20131008 - uxda - human talk

Exemple de code

Exemples de code tiré de http://mikehadlow.blogspot.fr/2010/09/separation-of-concerns-with-domain.html

Page 11: 20131008 - uxda - human talk

Quelques pratiques complémentaires…BDD : cette pratique va dans le même sens, cf. vidéo Emilien Pecoul des Human Talks de mai 2013

Nombreuses pratiques autour de la POO : SRP (Single Responsability Principle), Dependency Inversion, Law of Demeter…pour structurer son code de manière à le rendre maintenable et évolutif

CQRS : séparation des responsabilités Command/Query = 2 modèles (agrégation de ressources => bcp d’autres depuis)

Event Sourcing : et si on se passait de SGBDR ? ;)

Page 12: 20131008 - uxda - human talk

MERCI

ROTI ?

Coding Dojo sur le sujet => rejoignez-nous

Pour aller plus loin sur les principes de POO et les métriques associées, RDV au MUG Lyon le 24 octobre 2013 à Sciences U

Page 13: 20131008 - uxda - human talk

Références

Martin Fowler : Pattern of Enterprise Application Architecture (Domain Model, Transaction Script, Query Object…)

Jeffrey Palermo : Onion Architecture + les 3 parties suivantes

Udi Dahan : Domain Events