[:fr]La parole est aux speakers : Arnaud Lemaire[:]

Publié le

[:fr]Jusqu’au PHP Tour Montpellier 2018, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence !

La conférence

CQRS, Fonctionnel, Event Sourcing & Domain Driven Design

Avec autant de buzzwords dans le titre, explicitons le menu 😕 – Nous commencerons avec une étude des principes du CQRS et la notion de projection pour construire les modèles de données dédiées à la lecture, le tout avec un datastore traditionnel (relationnel). ? – Nous continuerons avec le concept d’état en programmation fonctionnelle, et comment les gérer au sein d’une application tout en respectant le principe d’immutabilité. Et comment ils ont transformé la gestion d’états pour la construction d’interface utilisateur. ? – Dans un troisième temps, nous nous intéresserons aux évènements du domaine-métier dans le Domain Driven Design et comment ceux-ci s’intègrent dans la mécanique de construction des projections. ?– Enfin, nous assemblerons toutes ces notions pour faire apparaitre l’«?event sourcing?» comme modèle de persistance pour nos données. ? – Pour clôturer, nous verrons les erreurs les plus courantes rencontrées lors de l’implémentation d’un modèle en event sourcing. Take away: ?– Utiliser CQRS (sans event-sourcing) pour simplifier la gestion de la persistance dans son application. ?– Comprendre comment gérer des états dans un contexte fonctionnel ? – Gérer facilement les évènements-métier au sein d’une architecture DDD. ?– Savoir comment implémenter correctement un système basé sur l’event sourcing.

Salle Jarvis
17/05/2018
16:25-17:05

Tu vas nous parler de DDD et d’Event Sourcing : as-tu eu l’occasion de voir de nombreux projets utilisant ces principes ?

L’approche du Domain Driven Design, comme principe pour la construction d’un logiciel, est devenue, pour moi, un prérequis pour le succès d’un projet logiciel. Le fait d’architecturer le logiciel, à partir du métier qu’il représente, est en effet le meilleur moyen d’éviter que ce dernier ne soit déphasé par rapport à celui-ci. C’est donc une pratique qui est maintenant intégrée dans mon quotidien de développeur.

A contrario, l’application des patterns techniques, comme l’Event Sourcing, est soumis aux contraintes du projet. Il s’agit d’outils qui permettent de bénéficier d’importants avantages, sur certains types de projets. Ces derniers ne doivent, toutefois, pas être appliqués aveuglément (comme n’importe quels autres patterns, d’ailleurs).

Travaillant à la fois en tant que développeur sur des applications pour le compte de clients tiers, mais aussi en accompagnement technique auprès de différentes équipes, j’ai la chance de pouvoir évoluer sur des projets diversifiés en termes de langages, d’industrie ou de taille. Autant de contextes qui m’ont permis de bénéficier d’une expérience éclectique sur la mise en place de ces principes.

Ces design pattern font beaucoup parler d’eux en ce moment : à ton avis, y a-t-il une règle pour savoir dans quels cas il faut les utiliser ?

Il faut distinguer, je pense, les concepts qui sous-tendent le Domain Driven Design et les patterns techniques d’application de ces principes (par exemple : CQRS, Event Sourcing, l’architecture hexagonale…).

Comme indiqué précédemment, je considère la question du Domain Driven Design comme indispensable dans tout projet de développement. Cette logique, consistant  à aligner l’architecture logicielle au plus proche du métier qu’elle est censée représenter, s’avère particulièrement nécessaire pour garantir une bonne maintenabilité dans le temps. Le métier étant quasi-systématiquement à l’origine des changements demandés dans une application, si le métier a été correctement représenté dans le code, une modification du métier aura un impact dans le code d’une magnitude équivalente (un petit changement métier demandera un petit changement de code et inversement).

Par contre, l’application de certains patterns techniques est à évaluer en fonction des besoins de l’application. Il n’est, d’ailleurs, pas rare de trouver des patterns d’architecture très différents au sein d’une même application. Enfin, certains patterns (comme l’event sourcing) demandent d’avoir une équipe qui a de l’expérience sur ces questions. Effectivement, ils amènent des contraintes qui peuvent se révéler fatales si l’implémentation est mal faite.

En dernier lieu, une erreur très courante est de ne pas distinguer les principes des patterns techniques. En effet, un projet qui ne se concentrerait que sur l’application des patterns techniques risque de passer complètement à côté de l’approche du Domain Driven Design.

.

Travailles-tu souvent avec PHP ? As-tu un language de prédilection ?

PHP reste le langage avec lequel j’ai démarré mon activité professionnelle. Je garde donc un certain attachement pour le langage. Dans mon activité de développeur, je suis cependant majoritairement sur des projets en Java. Maintenant, une partie de mon activité se faisant en accompagnement d’équipe, je suis régulièrement amené à travailler sur des projets en PHP. C’est la raison pour laquelle je continue à effectuer une veille active sur cet écosystème même s’il ne s’agit plus de mon langage de travail au quotidien.

Pour conclure, les langages de programmation sont, pour moi, des outils me permettant de construire une solution à une problématique métier donnée. Ainsi la question du langage de prédilection ne se pose que dans un contexte donné (technique, business et humain) et non de manière générale. C’est pourquoi je m’intéresse aux problématiques de conception logicielle et d’architecture, car ces principes sont transposables, quel que soit le langage utilisé (avec quelques adaptations liées aux capacités du langage, bien entendu).

Une conférence présentée par

Arnaud LEMAIRE
Arnaud LEMAIRE
Arnaud a été tour à tour (et pas dans le bon ordre) : CTO d’une startup, directeur de la production chez un éditeur logiciel, architecte logiciel, consultant et développeur. Après avoir travaillé pour des Startups, des PME, des grands groupes et le secteur public, il est maintenant membre d’un bureau d’étude pour aider des clients de toute taille à réussir leurs projets logiciels depuis la conception jusqu’au déploiement en production.

Autres interviews

[:]