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

[: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

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

• [:fr]La parole est aux speakers : Sarah Haïm-Lubczanski[:]
• [:fr]La parole est aux speakers : Romain Monceau [:]
• [:fr]La parole est aux speakers : Ulrich Lusseau[:]
• [:fr]La parole est aux speakers : Kevin Dunglas[:]
• [:fr]La parole est aux speakers : Joel Wurtz[:]
• [:fr]La parole est aux speakers : Quentin Pautrat[:]
• [:fr]La parole est aux speakers : Julien Vinber[:]
• [:fr]La parole est aux speakers : Edouard Cunibil[:]
• [:fr]La parole est aux speakers : Nicolas Grekas[:]
• [:fr]La parole est aux speakers : Jean Pasdeloup et Romain Cottard[:]
• [:fr]La parole est aux speakers : Frédéric Hardy[:]
• [:fr]La parole est aux speakers : Benoit Jacquemont[:]
• [:fr]La parole est aux speakers : Nicolas Wurtz[:]
• [:fr]La parole est aux speakers : Derick Rethans[:]
• [:fr]La parole est aux speakers : Hannes Van De Vreken[:]
• [:fr]La parole est aux speakers : Cédric Spalvieri[:]
• [:fr]La parole est aux speakers : Michael Bodnarchuk[:]
• [:fr]La parole est aux speakers : Hélène Schapira[:]
• [:fr]La parole est aux speakers : Mathieu Santostefano[:]
• [:fr]La parole est aux speakers : Grégoire Pineau[:]
• [:fr]La parole est aux speakers : Richard Hanna[:]
• [:fr]La parole est aux speakers : Julien Pauli[:]