Grégory Weinbach
✉️ InviterCTO, senior developer, software architect, Domain Driven Designer, modelling addict
Talks
Il n'y a pas de bon modèle métier
On vous le répète : une application répond bien aux besoins de ses utilisateurs si elle reflète bien leur métier. Les approches du développement centrées sur l’Utilisateur sont d’ailleurs faites pour ça : le DDD d’Eric Evans concentre ses efforts sur la modélisation du “Coeur du Domaine”.
En pratique, comment faire un “bon” Modèle Métier ?
Traditionnellement, on dit qu’il faut représenter au mieux la réalité de ce métier : faire “coller” le code au plus près du monde réel pour garantir l’adéquation au besoin.
Malheureusement, cette approche naïve est mauvaise ! Pourquoi ? Parce qu’un logiciel ne représente pas le monde réel, il informatise des services rendus.
Parce qu’un Modèle de Domaine n’est pas un Modèle du Métier, c’est un modèle de conception répondant à des exigences de codage.
Et je vous montrerai, à partir d’exemples, pourquoi il ne doit pas être construit en observant le monde réel mais à partir des besoins de présentation ou de services.
En pratique, comment faire un “bon” Modèle Métier ?
Traditionnellement, on dit qu’il faut représenter au mieux la réalité de ce métier : faire “coller” le code au plus près du monde réel pour garantir l’adéquation au besoin.
Malheureusement, cette approche naïve est mauvaise ! Pourquoi ? Parce qu’un logiciel ne représente pas le monde réel, il informatise des services rendus.
Parce qu’un Modèle de Domaine n’est pas un Modèle du Métier, c’est un modèle de conception répondant à des exigences de codage.
Et je vous montrerai, à partir d’exemples, pourquoi il ne doit pas être construit en observant le monde réel mais à partir des besoins de présentation ou de services.
Lean Enterprise Architecture
Les équipes d’architecture d’entreprise accouchent souvent de monstres prométhéens dont la destinée est de garnir d’énormes armoires (virtuelles).
La clé de l’adoption de l’architecture d’entreprise par les équipes opérationnelles est évidemment son utilité : il faut rendre l’architecture d’entreprise la plus « lean » possible, c’est-à-dire la concentrer sur la valeur ajoutée.
Nous verrons que si cela passe souvent par une simplification des frameworks, c’est d’abord dans le travail quotidien du modélisateur que réside la solution : se concentrer sur l’objectif de chaque modèle, sur l’intention de chaque diagramme, revenir au sens derrière chaque élément de modélisation et apprendre quand ne pas modéliser.
La clé de l’adoption de l’architecture d’entreprise par les équipes opérationnelles est évidemment son utilité : il faut rendre l’architecture d’entreprise la plus « lean » possible, c’est-à-dire la concentrer sur la valeur ajoutée.
Nous verrons que si cela passe souvent par une simplification des frameworks, c’est d’abord dans le travail quotidien du modélisateur que réside la solution : se concentrer sur l’objectif de chaque modèle, sur l’intention de chaque diagramme, revenir au sens derrière chaque élément de modélisation et apprendre quand ne pas modéliser.
UX : le Poids des Mots...
L’expérience utilisateur est un problème trop sérieux pour le confier à des graphistes ! Une bonne (ou une mauvaise) ergonomie ne se détermine pas en conception : à ce moment, il est déjà bien trop tard.
L’UX, c’est d’abord une affaire de mots : de bonnes (ou de mauvaises !) questions posées aux utilisateurs et des réponses formulées avec précision.
Où l’on apprend qu’une User Story (ou un Cas d’Utilisation) mal intitulée peut mutliplier par quatre le nombre d’écrans et qu’entre un “un” et un “mon”, il y a trois clicks de souris… et que même une démarche agile peinera à rectifier ce qui se décide dès la Vision projet.
L’UX, c’est d’abord une affaire de mots : de bonnes (ou de mauvaises !) questions posées aux utilisateurs et des réponses formulées avec précision.
Où l’on apprend qu’une User Story (ou un Cas d’Utilisation) mal intitulée peut mutliplier par quatre le nombre d’écrans et qu’entre un “un” et un “mon”, il y a trois clicks de souris… et que même une démarche agile peinera à rectifier ce qui se décide dès la Vision projet.