UXDA : une architecture
logicielle pilotée par
l'eXpérience Utilisateur
Human Talks Lyon – Octobre 2013 – Hébergé par La C...
Qui suis-je ?
Architecte/chef de projet/consultant mais avant tout
ARTISAN DEVELOPPEUR
> Twitter : @clem_bouillier
Membre ...
10 minutes pour aller plus loin
1. Limites des applications CRUD et d’une architecture 3-tiers « type »
2. Des application...
Applications CRUD
Create
Read
Update
Delete
CRUD
INSERT
SELECT
UPDATE
DELETE
SGBDR
=> Un objet cible => Une table
Je vais ...
Applications CRUD
Create
Read
Update
Delete
CRUD
WTF ?!? Pourquoi dois-je
m’adapter à un outil qui était
sensé m’aider ?
...
Architecture en couche type
Présentation/IHM
Objets
métier
Services
métier
Accès aux données
CRUD sur les objets métier
Ob...
Démarche UX (User eXperience) et agilité
UX est une démarche de conception visant à se
concentrer sur les usages de l’util...
L’architecture en oignon (Onion Architecture)
UXDA : une architecture « UX friendly »
1) Introspection des usages des utilisateurs
=> appropriation de l’Ubiquituous Lan...
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...
MERCI
ROTI ?
Coding Dojo sur le sujet => rejoignez-nous
Pour aller plus loin sur les principes de POO et
les métriques ass...
Références
Martin Fowler : Pattern of Enterprise Application Architecture (Domain
Model, Transaction Script, Query Object…...
Prochain SlideShare
Chargement dans…5
×

20131008 - uxda - human talk

764 vues

Publié le

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

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
764
Sur SlideShare
0
Issues des intégrations
0
Intégrations
159
Actions
Partages
0
Téléchargements
3
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

20131008 - uxda - human talk

  1. 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. 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. 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. 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. 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. 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. 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. 8. L’architecture en oignon (Onion Architecture)
  9. 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. 10. Exemple de code Exemples de code tiré de http://mikehadlow.blogspot.fr/2010/09/separation-of-concerns-with-domain.html
  11. 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. 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. 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

×