DDD, CQRS et Event Sourcing :quand coder propre n'est pas

suffisantJoseph Pachod

https://twitter.com/joeclueless

DISCLAIMERS

Applications partielles

Juste des approches

Applications partielles principales➢ Framework closed source d'Event Sourcing en

2009➢ DDD au quotidien, mais sur du code historique=> pas de projet « from scratch » jusqu'ici

DDD/CQRS/ES sont justes des approches➢ pas d'implémentations prêtes à consommer➢ principes généraux facilement applicables➢ multitudes de mises en œuvre possibles (tant au

niveau des choix architecturaux que desproduits/frameworks existants)

=> de la matière à penser !

Coder propre nécessaire mais...

Coder propre  : plein de règles applicableslocalement, bien moins à l'échelle d'une application.

Capture du métier ?

Comment capturer le métier ?➢ Couches techniques souvent plus simples à

organiser➢ Conservation des connaissances métier de façon

pérenne ?➢ Quel support pour les connaissances métier ?

Tout le métier peut appeler tout le métier : codespaghetti ?

Tout le métier peut appeler tout le métier➢ Tout peut dépendre de tout➢ Une partie, même mineure, peut casser toute

l'application si elle a un problème➢ Complexité résultante importante

Conception dirigée par le domaine

(Domain-Driven Design - DDD)

Voyons comment DDD peut apporter des élémentsde réponse.

Livre clé, aujourd'hui un peu dépassé sur certainspoints (dixit Evans lui même)

L'auteur a longuement pratiqué son approche avantque Martin Fowler ne vienne travailler avec lui et leconvainque d'écrire un livre et communiquer sur celleci, nommée Domain Driven Design à l'occasion.

Pré requis

Travail itératifAccès direct aux experts du domaine

Métier complexe

Travail itératif ➢ Juste du premier coup impossible➢ Raffinement au cours du temps➢ Aller/retour nécessaires avec les experts du

domaine

Langage Omniprésent

(Ubiquitous Language)

Langage des experts du domaine, utilisé égalementpar les développeurs et dans le modèle, c'est à direle code.

Nécessité de bien se comprendre et de reporter celajusque dans le code.

Le modèle doit communiquer comment fonctionne ledomaine, afin de faciliter sa compréhension et samise en œuvre.

A utiliser tout le temps

Rendre l'implicite explicite

Dans le code et à l'oral➢ Précision du langage➢ Capacité à détecter les problèmes

Si quelque chose sonne faux dans le langageomniprésent : revoir le vocabulaire et refactorer

Rendre l'implicite explicite➢ faire ressortir les concepts➢ écouter le langage des utilisateurs experts (mots

succincts pour des choses compliquées, correctiondu vocable des développeurs, éclairs decompréhension avec certains mots)

➢ examiner les maladresses➢ réfléchir sur les contradictions➢ apprendre le domaine fonctionnel (via des livres

consacré au métier par exemple)

Concepteurs les mains dans le code

(hands on modelers)

Le code est primordial pour valider le modèle et lesrefactoring, il faut que ceux qui modélisent touchentégalement au code. Ce dernier fait alors office degarde fou, rappelant les réalités du modèle, mais sertégalement à valider les changements.

Qui plus est, cela garantie la pérennité du modèle,qui ne peut pas diverger du code s'il est directementdans le code.

Mise en œuvre "tactique"

Eric Evans parle de niveau « tactique ».

Cette mise en œuvre souvent reprise au pied de lalettre, surtout en .Net. DDD a d'ailleurs eu plus desuccès en .Net qu'en Java.

Architecture en couchesInterface utilisateur, application, domaine, infra

La couche application :➢ lance les actions dans la couche domaine,➢ ne peut avoir qu'un état transitoire, du fait des

actions en cours, mais d'état demeurant au-delà.

=> la couche domaine est le coeur d'une applicationmétier, tout le métier doit s'y trouver

Entités, objets valeurs et services sans état…

(entities, value objects, stateless services…)

Objets valeurs  : immuables, pas d'identité, égalitédéfinie par les valeurs de leur champs.

Services :➢ L’opération exécutée par le Service fait référence à

un concept du domaine qui n’appartient pasnaturellement à une Entité ou un Objet-Valeur.

➢ L’opération effectuée fait référence à d’autresobjets du domaine.

➢ L’opération n’a pas d’état.

Gestion du cycle de vie :agrégats et entrepôts

(aggregates and repositories)

Agrégat :➢ une entité racine, seule référence persistante

possible du reste du monde vers l'agrégat➢ peut contenir des entités en interne, avec des

identifiants valables localement➢ peut référencer d'autres entités racines

➢ gère ses modifications et ses invariants (limitetransactionnelle)

Entrepôt :➢ unique façon d'obtenir des instances d'agrégat➢ encapsule les détails d'infra (SQL, en mémoire…)

➢ accès via méthodes ou spécifications➢ aucun accès direct aux données par le code tiers

➢ peut faire des calculs

=> limite les relations superflues (couplage faible),renforce la cohésion, facile connaissance etrefactoring

Refactoring continu

Le modèle doit toujours refléter le langageomniprésent et chacun de ses raffinements.

En maintenant toujours le modèle propre et encontinuant à vouloir restituer le domaine au mieux, ilarrive parfois que l'on fasse des « percées » : éclairsde compréhension validés par le code et améliorantde façon significative le code.

Préserver l'intégrité du modèle quand lacomplexité croît

Si on utilise le même terme pour des usagesdifférents, les besoins de modélisation risquent dediverger à terme, entrainant un objet incohérent.

De plus, la cohésion et l'unicité du langageomniprésent sont mis en péril dès que le nombred'interlocuteurs augmente, surtout de développeurs.

=> un modèle unique pour tout le logiciel est difficile,voir utopique

Quid de l'interfaçage avec du code tiers ?

Niveau stratégique

Contexte borné

(bounded context)

Une équipe peut travailler sur plusieurs contextes, uncontexte ne peut être manipulé que par une équipe.

Définir les limites précises, quels concepts sontinclus, quels besoins.

Le contexte borné doit protéger son modèle du restedu code, l'isolant afin de pouvoir le faire évoluer sansnécessairement impacter le reste du monde, saufpour des contextes bien identifiés.

Carte de contexte

(context map)

Identifie les différents contextes bornés et leursrelations.

Les noms des contextes font partie du langageomniprésent, facilitant grandement les discussions.

Plusieurs types d'interactions entre contextespossibles, existence de patterns.

Couche anti corruption(anti corruption layer)

Pattern fondamental  : illustre bien la nécessité deprotéger l'intérieur du contexte de l'extérieur.

Le but est de ne pas polluer le contexte avec desnotions/structures externes. De même l'extérieur nedoit pas dépendre de l'intérieur du contexte, afin detoujours permettre le refactoring.

Noyau partagé(shared kernel)

Client-fournisseur(customer/supplier)

Couche anti corruption(anti corruption layer)

Conformiste(conformist)

Chemins séparés(separate ways)

Collaboration

+

-

Noyau partagé : une partie du contexte est communeà plusieurs contextes. Cette partie doit évoluer enaccord avec les équipes de chaque contexte.En général plusieurs équipes avec un responsablecommun.

Client fournisseur  : le fournisseur prend en compteles remarques des clients mais décide à sa manièreet informe les clients. En général équipes sans lienhiérarchique opérationnel.

Conformiste  : on ne veut modifier qu'une partie d'ungrand tout, aussi on se conforme au tout.

Chemins séparés : on évite de mettre quoique ce soiten commun, car les contextes sont indépendants.

Langage publié(published language)

Service hôte ouvert(open host service)

Couche anti corruption(anti corruption layer)

Ouverture

+

-

Un service hôte ouvert propose une API réutilisablepar différents contextes pour interagir avec lecontexte courant.

Un langage publié est utilisé en tant que tel par toutle monde, chacun pouvant l'intégrer dans soncontexte si besoin. Il s'agit par exemple d'un langagede description des interactions chimiques : dans uneentreprise pharmaceutique toutes les équipespeuvent à terme s'en servir.

En résumé

En résumé

Distiller pour aller à l'essentiel

Avec le temps, on améliore (distille) le modèle pourenlever l'accessoire, se concentrant sur l'essentiel.

Privilégier le cœur de domaineGuider en explicitant sa vision

(core domain - domain vision statement)

Le coeur de domaine est le contexte apportant la plusgrande valeur à l'entreprise. Aussi il s'agit du contextedont il faut s'assurer le meilleur développement  : ilfaut y concentrer tant les moyens financer que lesmeilleurs développeurs. Le but est d'avoir desrésultats les meilleurs possibles dans le coeur dedomaine.

Le périmètre et l'ambition de ce coeur de domainepeuvent être explicités par une «  vision  », afin quel'équipe en charge de contexte sache clairement oùse trouve la valeur ajoutée et ce qu'il faut privilégier.

Sortir l'accessoire du cœur de domaine

En introduisant des sous domaines génériques pourgarder le domaine essentiel au coeur.

Sortir des mécanismes cohérents en soi du domainepour les mettre dans des librairies.

Remarques & avis personnel

Modélisation « tactique » au choix de l'équipe

La notion de contexte évite qu'un contexte ne viennepolluer un autre.

Aussi, tant qu'à faire, que chaque contexte fasse leschoix techniques qui lui conviennent le mieux, afin derépondre à ses propres besoins.

L'approche tactique présentée par Eric Evans est, àce titre, qu'un exemple. Un contexte purementfonctionnel ou basé sur Matlab a tout autant sa place.

Les contextes sont votre cœur de métier : assurezleur pérennité

Si la partie présentation peut évoluer et changer dutout au tout au cours du temps, la logique métier descontexte doit elle être conservée quoiqu'il arrive,même dans le cas de portage sur une plateformemobile.

Aussi, il faut éviter de dépendre de frameworks dontla pérennité est incertaine (évolution dans un senscontraire aux attentes de l'équipe, voir, pire, arrêt dudéveloppement de ce dernier) ou qui affectentprofondément le code, réduisant sa portabilité.

Cas des Frenchies et autres non anglophones

Si les experts du domaine parlent en français, il fautque le modèle soit également en français, pour qu'ilsoit toujours utilisable directement avec lesutilisateurs.

De plus cela évite le « bruit mental » à chaque lecturedu modèle, où une traduction doit être faite à la voléepour trouver les termes correspondant dans la languedu métier.

Si plusieurs langues sont utilisées par les experts dudomaine, en choisir une et fournir des glossaires pourles autres.

Lisez le livre !

Le livre est vraiment très bien, bourré d'exempleséclairant et de remarques pertinentes.

I l aborde également la problématique desapplications à très large échelle, proposant desapproches pour faciliter celles ci. Ces aspects nesont pas présentés ici : si vous avez de tels besoins,alors il vous faudra de toutes façons obligatoirementlire le livre !

Mais...tout le métier est dans un même processus

Dans ce qui a été présenté, « techniquement » tout lemétier peut appeler tout le métier  : possibilitéd'interférer avec du code d'autres contextes, parexemple en manipulant le classpath.

De plus, une erreur, venant par exemple d'une tâchesans importance, peut arrêter toute l'application (OutOf Memory en Java par exemple).

Tout avoir dans un même processus est donc fragile :comment combler la chose ?

Architecture orientée événements

(Event-driven architecture ou Event Sourcing)

Rich Hickey est le créateur de Clojure et une despersonnes derrière Datomic, une base de donnéesorientée événements.

Il a une profonde compréhension des éléments àl'oeuvre en informatique et ses présentations sontvraiment très instructives à chaque fois.

Il est l'une des personnes derrière le renouveau de lanotion d'événements.

La base de données contient un sous ensembledes traces.

(The database is a subset of the logs.)

Pour débogguer une application, on consultegénéralement ses traces, au moins autant que l'étatde la base de données voir plus.

N'est ce pas paradoxal d'avoir tant d'informationsdans un fichier plat non structuré, qui plus estgénéralement supprimé à brève échéance ? Ne perdt on pas ainsi plein d'informations utiles ?

La vraie vie :pas de mise à jour, seulement des événements.

Date et données d'un événement ne changentpas.

Seuls de nouveaux événements s'ajoutent.

En réalité, il n'y a pas de mises à jour « in place »similaires aux update en base de données.

Idées :● stocker les événements

● construire l'état courant à partir des événements

Publication et consommation via un busd'événements

Exemples d'événements

UserAuthenticated(userId, date)ItemAdded(itemId, number, cartId, date)

ItemRemoved(itemId, cartId, date)

Une vue : événements agrégés

Souscrire aux événements désirés et créer desvues.

Satisfaire exactement le besoin !

● Duplication des données dans différentes vues● Données au format consommé

L'espace disque n'est plus une limite

Besoin de reconstruire une vue ?

Faire des instantanés (snapshots) : sauvegardede l'état de la vue à un événement donné 

Publication/souscription : asynchrone

● Code construit avec possibilité de distribution=> montée en charge

● L'émetteur de l'événement ignore tout dessouscripteurs, l'événement est le seul contrat à

honorer=> piles techniques différentes possibles,

ouverture sur le reste du monde

Conservation des événements suite à leurpublication

● historique du système

● capacité à rejouer tout ou partie● consommation décalée possible

Résumé de l'Event Sourcing

● Changements communiqués via publicationd'événements

● Événements conservés● Événements agrégés dans des vues

Retour au Domain Driven Design

Événements pour échanger entre contextesbornés

Vues pour mieux servir les lectures du domaine

Code des contextes vraiment indépendant les unsdes autres, voir même les piles techniques

Historique

Event Sourcing basé sur les faits, comment gérerles choses à faire ?

Ségrégation des Responsabilités de Commandeet de Requête

Command Query Responsibility Segregation

Greg Young est un pratiquant et promoteur de longuedate de l'approche CQRS et a depuis participé àl'élaboration d'eventstore, une base de donnéesorientée événements.

Udi Dahan est derrière NServiceBus, un bus decommandes et événements, et dispose d'une trèsgrande expérience du CQRS qu'il expose avecbeaucoup de pertinence sur son blog.

Tous deux viennent du monde .Net.

Constat : la base de données est un gouletd'étranglement des performances et de la

modélisation

Dans une base de données relationnelles, écritureset lectures sont en opposition  : les écrituresconcernent généralement peu de tables à la fois, surdes colonnes très précises, tandis que les lecturesconcernent plusieurs tables et remontent beaucoupd'informations.

Quand la charge augmente, les transactionscorrespondantes aux mises à jour ralentissent tout lemonde, créant de véritables goulet d'étranglement.

Qui plus est, lors de la conception, la base dedonnées est un compromis de modélisation visant àsatisfaire tant l'écriture que la lecture.

Le temps CPU d'un serveur de base de donnéespeut être utilisé à 80 % par la gestion des

transactions.

Dixit Rich Hickey, de mémoire.

Idée : séparons lecture et écriture

Écriture (Write side – Command) : une base dedonnées

Lecture (Read side - Request) : réplication de labase d'écriture vers une ou plusieurs bases de

données

Écriture et lecture séparées : pourquoi garder lemême modèle ?

Besoins très différents : même modèle impliquedes compromis

Constat :Les écritures en base ressemblent aux

événements

Similitudes● Ont une date

● Contiennent des données exprimant unedemande

Différences● Peuvent échouer

● S'ils réussissent, déclenchent des événements

Introduction de la notion de commande :● Une date

● Une demande exprimée par les données● Peut réussir ou non

Modèle d'écriture (Write Model)

● traite les commandes● émet des événements lorsqu'il accepte les

commandes● assure les invariants (en ayant un état)

Granularité fine des changements

Changements via des commandes, plus des entités :on peut aisément ne changer qu'une valeur, pasbesoin de tout transporter.

Interface utilisateur centrée sur les tâches(tasks focused UI)

Si à un endroit l'utilisateur a des infos sur une souspartie d'un concept, pas besoin de lui proposerl'édition de l'ensemble de ce concept, on peut seconcentrer sur ce que lui permet sa tâche !

Stockage de l'état du domaine d'écriture

● Centré sur les invariants lors de l'écriture● Granularité fine● Charge limitée

● Besoin d'un support des transactions

Candidats nombreux (bases relationnelles ouautres)

Ébauche d'une réponse au problème initial

● Capture du métier via le langage omniprésent● Intégrité assurée via les contextes bornés● Les contextes valident les commandes et

émettent les événements● Les vues agrègent les événements et permettent

la lecture

Consistance à terme

Consistance souvent illusoire

En réalité, de nombreux éléments induisent que laconsistante n'est pas absolue :➢ Écrans non rafraîchis➢ Cache divers➢ Systèmes non entièrement transactionnels➢ Niveau de transaction baissé pour raisons de

performances

De quoi parle-t-on ?

Données anciennes, pas faussesPerformances meilleures que du synchrone

Opportunité d'améliorer

Vitesse de rafraîchissementSurveillance & ajout de nœuds

Au niveau de l'interface utilisateur

Bloquer en attendant les résultatsIndiquer l'en cours

Combiner les deux...

L'asynchrone est l'occasion de fonctionner ainsi :➢ Envoi de la commande, conservation d'un

identifiant unique (UUID)➢ Attente de la mise à jour de la vue correspondante

via l'apparition dans celle de l'identifiant de lacommande

➢ Si l'attente dépasse un certain délai (200ms parexemple), indiquer à l'utilisateur que sa demandeest en cours et qu'il sera notifié de son succès, puisle laisser procéder à la suite de ses actions

Initialement...

Tout dans un processusUne couche métier

Une base de données(un framework)

un monolithe !

Tout dans un processus➢ Appels synchrones➢ Quid de p lus ieurs nœuds (per formance,

redondance) ?

Une couche métier➢ Tout le code métier peut appeler tout le code métier➢ Pas de séparation physique du code métier.➢ Chaque entité ou concept est susceptible d'être

utilisé dans n'importe quel autre bout de code,même pour des besoins divergeant.

Une base de donnés➢ Compromis entre les différents besoin métier➢ Goulet d'étranglement

Framework ➢ Quid si évolue dans un sens non désiré ?➢ Quid s'il n'est plus maintenu ?

Monolithe : coûts exponentiels avec letemps

Montées en charge difficile● Du nombre d'utilisateur● Du nombre de fonctionnalités● Du nombre de développeurs

Utilisation de systèmes tiers non prévue

Plus le temps passe, plus l'évolution du monolithedevient difficile et couteuse.

De plus, le jour où il faut s'ouvrir à des systèmestiers, tout est à faire au sein du monolithe où rienn'est pensé pour des interactions avec des tiers.

CONCLUSION

Système distribué

Monolithe

Application desktop/mobileSite promotionnel temporaire

Web Scale, SaaS

Application web

Haute disponibilité, montée en charge,pérennité, intégration technologique

Facilité de mise en œuvre, court/moyen terme

L'approche présentée dans cette présentation revientà celle d'un système distribué, du fait de l'asynchronepermettant la distribution.

Cette approche «  système distribué  » a sesavantages mais est complexe et avec une fortecourbe d'apprentissage.

Un monolithe, à l'inverse, est bien plus facile etrapide à mettre en œuvre.

Les deux concepts ont donc leurs cas d'usage.

Choisissez votre poison &

amusez vous !

Pour avancer concrètement

Frameworks/librairies souvent trop générales

Approfondir via des implémentations d'event bus(Kafka)

Les frameworks ou librairies tentent généralement des'accommoder de toutes les bases de données,tentant de se baser sur un socle commun minimal.

Ce socle commun est donc très limité, amenant denombreuses difficultés à comprendre comment un telframework peut fonctionner.

Une fois que des bases de données orientéesévénements sont considérées, tout s'éclaire : celles cifournissent de nombreuses fonctionnalités s'adaptanttrès bien au problème. Elles fournissent donc unebonne base pour comprendre les diverses solutionsretenues, pour ensuite faire ses choix et mettre unframework ou une librairie par dessus.

Remerciements

Les personnes citées auparavantUwe Schäfer (@codesmell) pour les discussions et l'expertise technique

Olivier Schneider (@Oli3dfx) pour les discussions et l'aide pour laprésentation

Pierre-Nicolas Horn, pour l'aide pour la présentation

A vous, pour être venu et avoir tenu si longtemps

Pour approfondir● Talks de Rich Hickey http://www.infoq.com/author/Rich-Hickey

● Talks de Greg Young http://www.infoq.com/author/Greg-Young

● The Log: What every software engineer should know about real-time data's unifyingabstraction http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

● Documentation Kafka https://kafka.apache.org/documentation.html

● Analyses de systèmes distribués https://aphyr.com/tags/Distributed-Systems

● Fallacies of Distributed Computing Explainedhttp://www.rgoarchitects.com/Files/fallacies.pdf

● Domain-Driven Design Vite fait http://www.rgoarchitects.com/Files/fallacies.pdf

● Clarified CQRS http://www.udidahan.com/2009/12/09/clarified-cqrs/