20131008 - uxda - human talk
DESCRIPTION
Support Human Tals Lyon 8 octobre 2013 UXDA : une architecture logicielle pilotée par l'eXperience UtilisateurTRANSCRIPT
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
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/
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 ?)
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
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 ?
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
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 ?
L’architecture en oignon (Onion Architecture)
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
Exemple de code
Exemples de code tiré de http://mikehadlow.blogspot.fr/2010/09/separation-of-concerns-with-domain.html
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 ? ;)
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
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