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

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 ?)

4. 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

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 ?

8. L’architecture en oignon (Onion Architecture)

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

13. 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