1. 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
2. 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/
3. 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 ?)
5. 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 ?
6. 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 Record
Services 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
7. 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 ?
9. 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
10. Exemple de code
Exemples de code tiré de http://mikehadlow.blogspot.fr/2010/09/separation-of-concerns-with-domain.html
11. 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 ? ;)
12. 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