DDD, CQRS et Event Sourcing :
quand coder propre n'est pas
suffisant
Joseph Pachod
https://twitter.com/joeclueless
Coder propre nécessaire mais...
Coder propre  : plein de règles applicables
localement, bien moins à l'échelle d'une appli...
Capture du métier ?
Comment capturer le métier ?
● couches techniques souvent plus simples à
organiser
● Conservation des ...
DDD - Domain-Driven Design
(Conception dirigée par le domaine)
Pas un framework ni une méthodo, plutôt une
approche
Livre clé, aujourd'hui un peu dépassé sur certains
points (dixit Evans lui même)
Auteur a longuement pratiqué son approche...
Pré requis
Travail itératif
Accès direct aux experts du domaine
Métier complexe
Ubiquitous Language
(Langage omniprésent)
Langage des experts du domaine, utilisé également
par les développeurs et dans l...
A utiliser tout le temps
Rendre l'implicite explicite
Dans le code et à l'oral
● Précision du langage
● Capacité à détecte...
Hands on modelers
(Concepteurs les mains dans le code)
Le code est primordial pour valider le modèle et les
refactoring, i...
Mise en œuvre "tactique"
Eric Evans parle « tactique »
Mise en œuvre reprise parfois au pied de la lettre,
notamment en .N...
Aggregate
(Agrégat)
Notion essentielle
Entities & Value Objects
(Entités & objets valeurs)
L'agrégat est la notion fondame...
Root
(Racine)
Entité principale de l’agrégat
Point de passage obligé
- seule l’entité racine peut être référencée par d'au...
Un agrégat assure sa cohérence
interne
En l’absence d’agrégat, la cohérence est assurée par
la transaction courante : tout...
Agrégat :
- une entité racine, seule référence persistante
possible du reste du monde vers l'agrégat
-- peut contenir des ...
Repository
(Entrepôt)
Point unique d'accès aux données stockées
Unité de stockage : l'agrégat
Un entrepôt assure la persis...
Layered architecture
(Architecture en couches)
Interface(s) utilisateur, application, domaine, infra
La couche application...
Couche domaine 
Tout le métier !
Aggregates, Entities, Value objects,
Stateless Services, Repositories…
(Agrégats, entités...
Couche infrastructure
Implémentation(s) des entrepôts
Librairies diverses
Implémentation(s) des entrepôts : le domaine ne ...
Refactoring continu
Le refactoring continu assure que le code reflète
toujours bien le langage omniprésent.
Qui plus est, ...
Préserver l'intégrité du modèle
quand la complexité croît
Même termes, usages différents, modélisation variant
à terme
Coh...
Niveau stratégique
Bounded context
(Contexte borné)
Définir les limites précises, quels concepts sont
inclus, quels besoins.
Le contexte born...
Anti corruption layer
(Couche anti corruption)
Shared kernel
(Noyau partagé)
Customer/supplier
(Client-fournisseur)
Anti corruption layer
(Couche anti corruption)
Confor...
Published langage
(Langage publié)
Open host service
(Service hôte ouvert)
Anti corruption layer
(Couche anti corruption)
...
Context map
(Carte de contexte)
Identifie les différents contextes bornés et leurs
relations.
Les noms des contextes font ...
Distiller pour aller à l'essentiel
En introduisant des sous domaines génériques pour
garder le domaine essentiel au coeur....
Core domain with a vision statement
(Domaine central avec une vision)
Il convient d’identifier le ou les domaines centraux...
Eric Evans
« What I've learned about DDD
since the book »
Conférence de 2009
Domain Events
On en reparle dans la suite : Eric Evans s'inspire des
mêmes éléments pour recommander les Domain
Events
Big Ball Of Mud
(grosse balle de boue)
Big Ball Of Mud
aussi en DDD
Mais…
DDD non possible au milieu d'une
Big Ball Of Mud
Modélisation « tactique »
au choix de l'équipe
Cf par exemple «  Functional and Reactive Domain
Modeling » (voir le livre ...
En complément...
Cas des Frenchies
(et autres non anglophones)
Comment faire quand on code dans un langage
informatique en anglais et que l...
Avoir des domaines pérennes
Les différentes couches Domaine représentent le
coeur de métier d’une entreprise.
Leur durée d...
Lisez le livre !
Mais...
tout le métier est dans un même
processus
Tout le métier peut appeler tout le métier 
● Tout peut dépendre de tout...
Event sourcing
The database is a subset of the logs
(La base de données contient un sous
ensemble des traces)
Une base de données peut êt...
Quid du monde réel ?
Pas de mise à jour, seulement des événements.
Date et données d'un événement ne changent pas.
Seuls d...
Evénement : date et données
Idées :
● stocker les événements
● construire l'état courant à partir des événements
Evénements publiés et
abonnements
Exemples d'événements
UserAuthenticated(userId, date)
ItemAdded(itemId, number, cartId, date)
ItemRemoved(itemId, cartId, ...
Etat courant dans des vues
Une vue : événements agrégés
Souscrire aux événements désirés et créer des vues.
Satisfaire exactement le besoin !
● Duplication des données dans différentes vues
● Données au format consommé
Snapshots
(Instantanés)
Besoin de reconstruire une vue ?
Faire des instantanés (snapshots) : sauvegarde de
l'état de la vu...
Event driven architecture
(Architecture orientée événements)
L'espace disque n'est plus une limite
Asynchrone donc distribuable
Publication/souscription : asynchrone
● Code construit avec possibilité de distribution
=> mo...
Découplage fort
● L'émetteur de l'événement ignore tout des
souscripteurs, l'événement est le seul contrat à
honorer
=> pi...
Conservation des événements suite
à leur publication
● historique du système
● capacité à rejouer tout ou partie
● consomm...
En résumé :
Événements, distribution
(conservation) et vues
● Changements communiqués via publication
d'événements
● Événe...
Retour au Domain Driven Design
Événements pour échanger entre contextes bornés
Vues pour mieux servir les lectures du doma...
Event Sourcing basé sur les faits,
comment gérer les choses à faire ?
CQRS
Command And Query Responsibility
Segregation
(Ségrégation des Responsabilités de
Commande et de Requête)
Base de données 
=
goulet d'étranglement
Constat : la base de données est un goulet
d'étranglement des performances et de ...
Une base de données peut
consommer 80% du CPU pour la
gestion des transactions.
Séparer lecture et écriture
Écriture (Write side – Command) : une base de
données
Lecture (Read side - Request) : réplicat...
Pourquoi garder un même modèle ?
Écriture et lecture séparées : pourquoi garder le
même modèle ?
Besoins très différents :...
Write Model
(Modèle d'écriture)
● traite les commandes
● émet des événements lorsqu'il accepte les
commandes
● assure les ...
Inspiration de l'Event Sourcing
Les écrites partagent beaucoup avec les
événements.
Similitudes
● Ecriture à date donnée
●...
Commande
Date, données, consommation
unique
Peut échouer
Introduction de la notion de commande :
● Une date
● Une demande ...
Granularité fine des changements
Changements via des commandes, non des entités :
on peut aisément ne changer qu'une valeu...
Stockage de l'état du domaine
d'écriture
● Centré sur les invariants lors de l'écriture
● Granularité fine
● Charge limité...
Ébauche d'une réponse au
problème initial
● Capture du métier via le langage omniprésent
● Intégrité assurée via les conte...
Eventual consistency
(Consistance à terme)
De quoi parle-t-on ?
Données anciennes, pas fausses
Performances meilleures que du synchrone
Améliorations aisées
Vitesse de rafraîchissement
Surveillance & ajout de nœuds
Consistance souvent illusoire
Écrans non rafraîchis
Transactions consécutives
Cache divers
Systèmes non entièrement transa...
Au niveau de l'interface utilisateur
Bloquer en attendant les résultats
Indiquer l'en cours
Combiner les deux...
Initialement…
un monolithe !
Tout dans un processus 
● Appels synchrones
● Quid de plusieurs nœuds (performance,
redondanc...
Monolithe 
=
coûts exponentiels avec le temps
Montées en charge difficile
● Du nombre d'utilisateur
● Du nombre de fonctio...
Système distribué
Monolithe
Application desktop/mobile
Site promotionnel temporaire
Web Scale, SaaS
Application web ?
Haut...
Choisissez votre poison
&
amusez vous !
Pour approfondir
● Talks de Rich Hickey http://www.infoq.com/author/Rich-Hickey
● Talks de Greg Young http://www.infoq.com...
Remerciements
Eric Evans, Rich Hickey, Greg Young : penseurs des concepts présentés 
Uwe Schäfer (@codesmell) pour les dis...
Prochain SlideShare
Chargement dans…5
×

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

2 352 vues

Publié le

Quand une application voit son nombre d’utilisateurs augmenter, ses fonctionnalités monter en flèche ou avoir bien plus de développeurs, coder propre n’est plus suffisant pour assurer la pérennité de l’application en question.

Aussi, cette présentation introduit les idées simples derrière l’approche Domain Driven Design. Ces idées, poussées jusqu’au bout de leur logique, impliquent une nouvelle façon de coder vraiment rafraichissante, bien plus pérenne et évolutive. Le tout au plus proche des utilisateurs et des développeurs.

Deux autres notions sont alors introduites, la Command Query Responsibility Segregation (CQRS) et l’Event Sourcing, deux idées distinctes du Domain Driven Design. Ces idées ouvrent de nouveaux horizons en matière de développement. De plus, le découplage entre lecture et écriture et l’utilisation d'événements s’intègrent parfaitement avec le Domain Driven Design. De quoi faire chauffer les cerveaux !

Cette présentation est la suite logique de la présentation Coder Propre dont les slides sont disponibles là http://fr.slideshare.net/cluelessjoe/coder-propre/.

Publié dans : Ingénierie
  • Soyez le premier à commenter

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

  1. 1. DDD, CQRS et Event Sourcing : quand coder propre n'est pas suffisant Joseph Pachod https://twitter.com/joeclueless
  2. 2. Coder propre nécessaire mais... Coder propre  : plein de règles applicables localement, bien moins à l'échelle d'une application.
  3. 3. 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 ?
  4. 4. DDD - Domain-Driven Design (Conception dirigée par le domaine) Pas un framework ni une méthodo, plutôt une approche
  5. 5. Livre clé, aujourd'hui un peu dépassé sur certains points (dixit Evans lui même) Auteur a longuement pratiqué son approche avant que Martin Fowler ne vienne travailler avec lui et le convainque d'écrire un livre et communiquer sur celle ci, nommée Domain Driven Design à l'occasion.
  6. 6. Pré requis Travail itératif Accès direct aux experts du domaine Métier complexe
  7. 7. Ubiquitous Language (Langage omniprésent) Langage des experts du domaine, utilisé également par les développeurs et dans le modèle, c'est à dire le code. Nécessité de bien se comprendre et de reporter cela jusque dans le code. Le modèle doit communiquer comment fonctionne le domaine, afin de faciliter sa compréhension et sa mise en œuvre.
  8. 8. 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 langage omnipré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, correction du vocable des développeurs, éclairs de compréhension avec certains mots) - examiner les maladresses - réfléchir sur les contradictions - apprendre le domaine fonctionnel
  9. 9. Hands on modelers (Concepteurs les mains dans le code) Le code est primordial pour valider le modèle et les refactoring, il faut que ceux qui modélisent touchent également au code. Ce dernier fait alors office de garde fou, rappelant les réalités du modèle, mais sert également à valider les changements. Garanti la pérennité du modèle, qui ne peut pas diverger du code s'il est directement dans le code.
  10. 10. Mise en œuvre "tactique" Eric Evans parle « tactique » Mise en œuvre reprise parfois au pied de la lettre, notamment en .Net
  11. 11. Aggregate (Agrégat) Notion essentielle Entities & Value Objects (Entités & objets valeurs) L'agrégat est la notion fondamentale du niveau tactique en DDD. Objets valeurs : immuables, pas d'identité, égalité définie par les valeurs de leur champs. Les entités ne sont pas des objets valeurs : leur égalité est définie par leur identifiant indépendamment de leurs attributs.
  12. 12. Root (Racine) Entité principale de l’agrégat Point de passage obligé - seule l’entité racine peut être référencée par d'autres agrégats - point d’accès obligé au contenu - l’agrégat prend généralement le nom de l’entité racine Cela : - limite les relations superflues -- un couplage faible -- modèle bien plus clair - renforce la cohésion -- une même entité ne peut être utilisée à tout va => facilite la connaissance et le refactoring Les Values Objects eux peuvent être réutilisés à tout va.
  13. 13. Un agrégat assure sa cohérence interne En l’absence d’agrégat, la cohérence est assurée par la transaction courante : toutes les entités impliquées changeront en une fois (ou pas). Les limites transactionnelles sont alors implicites : la portée réelle de chaque transaction est ambiguë. Une nouvelle relation peut ainsi impacter beaucoup de cas d’usage sans s’en rendre compte. Les agrégats évitent cet écueil : ce qui va ensemble et doit être sauvé en une fois est indiqué explicitement. Assurer la cohérence interne implique également de tout vérifier au niveau du code Java, sans reposer sur des contraintes en base qui seront cachées des développeurs.
  14. 14. 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 (limite transactionnelle) – explicite les limites transactionnelles
  15. 15. Repository (Entrepôt) Point unique d'accès aux données stockées Unité de stockage : l'agrégat Un entrepôt assure la persistance des données: - encapsule les détails d'infra (SQL, en mémoire...) - accès aux données via méthodes ou spécifications -- aucun accès direct aux données par le code tiers autorisé => non dispersion de requêtes dans le code métier (celles ci sont exposées via des méthodes de l'entrepôt) - peut faire des calculs/regroupement sur les données stockées -- inutile de monter en mémoire chaque agrégat pour calculer l'âge moyen des voitures - unique façon d'obtenir des instances d'agrégats - se présente comme une API de collection
  16. 16. Layered architecture (Architecture en couches) Interface(s) utilisateur, application, domaine, infra La couche application : rôle de coordinateur - lance les actions dans la couche domaine, - ne peut avoir qu'un état métier transitoire, du fait des actions en cours, pas d'état demeurant au- delà. -- elle peut par contre stocker des données de contexte (session courante…) - gère les transactions
  17. 17. Couche domaine  Tout le métier ! Aggregates, Entities, Value objects, Stateless Services, Repositories… (Agrégats, entités, objets valeurs, services sans état, entrepôts…) Stateless Services dans les cas suivants : 1. L’opération exécutée par le Service fait référence à un concept du domaine qui n’appartient pas naturellement à une Entité ou un Objet-Valeur. 2. L’opération effectuée fait référence à d’autres objets du domaine. 3. L’opération n’a pas d’état – tout état est inclus dans un agrégat => la couche domaine est le coeur d'une application métier, tout le métier doit s'y trouver
  18. 18. Couche infrastructure Implémentation(s) des entrepôts Librairies diverses Implémentation(s) des entrepôts : le domaine ne doit pas dépendre d’une implémentation Librairies diverses : par exemple pour le support des transactions
  19. 19. Refactoring continu Le refactoring continu assure que le code reflète toujours bien le langage omniprésent. Qui plus est, le refactoring améliore la proximité avec le code, permettant de mieux en saisir le modèle et les nuances. Avec le temps, il arrive ce qu'Eric Evans nomme des percées : des éclairs de compréhension du domaine qui se répercutent par des changements significatifs du modèle. Bien souvent des aspects pénibles du modèle sont alors supprimés et d'anciennes incompréhensions ou incohérences s'expliquent.
  20. 20. Préserver l'intégrité du modèle quand la complexité croît Même termes, usages différents, modélisation variant à terme Cohésion et unicité du langage omniprésent mis en péril dès que le nombre d'interlocuteurs augmente Coût de la coordination Un modèle unique pour tout le logiciel est difficile, voir utopique Quid de l'interfaçage avec du code tiers ?
  21. 21. Niveau stratégique
  22. 22. Bounded context (Contexte borné) Définir les limites précises, quels concepts sont inclus, quels besoins. Le contexte borné doit protéger son modèle du reste du code, l'isolant afin de pouvoir le faire évoluer sans nécessairement impacter le reste du monde, sauf pour des contextes bien identifiés. Une équipe peut travailler sur plusieurs contextes, un contexte ne peut être manipulé que par une équipe.
  23. 23. Anti corruption layer (Couche anti corruption)
  24. 24. Shared kernel (Noyau partagé) Customer/supplier (Client-fournisseur) Anti corruption layer (Couche anti corruption) Conformist (Conformiste) Separate ways (Chemins séparés) Collaboration + -
  25. 25. Published langage (Langage publié) Open host service (Service hôte ouvert) Anti corruption layer (Couche anti corruption) Ouverture + -
  26. 26. Context map (Carte de contexte) Identifie les différents contextes bornés et leurs relations. Les noms des contextes font partie du langage omniprésent, facilitant grandement les discussions. Plusieurs types d'interactions entre contextes possibles, existence de pattern
  27. 27. Distiller pour aller à l'essentiel En introduisant des sous domaines génériques pour garder le domaine essentiel au coeur. Sortir des mécanismes cohérents en soi du domaine pour les mettre dans des librairies.
  28. 28. Core domain with a vision statement (Domaine central avec une vision) Il convient d’identifier le ou les domaines centraux de l’entreprise. Il s’agit généralement de ceux les plus profitables. Eric Evants préconise de leur associer une « vision claire », c’est à dire une phrase résumant leur nature et leur objectif, afin de s’assurer de ne pas en diverger par accident. Il faut également attribuer à ces domaines le plus de ressources notamment : - privilégier les domaines centraux dans les arbitrages, - y affecter les meilleurs développeurs.
  29. 29. Eric Evans « What I've learned about DDD since the book » Conférence de 2009
  30. 30. Domain Events On en reparle dans la suite : Eric Evans s'inspire des mêmes éléments pour recommander les Domain Events
  31. 31. Big Ball Of Mud (grosse balle de boue)
  32. 32. Big Ball Of Mud aussi en DDD
  33. 33. Mais… DDD non possible au milieu d'une Big Ball Of Mud
  34. 34. Modélisation « tactique » au choix de l'équipe Cf par exemple «  Functional and Reactive Domain Modeling » (voir le livre du même nom pour plus de détails).
  35. 35. En complément...
  36. 36. Cas des Frenchies (et autres non anglophones) Comment faire quand on code dans un langage informatique en anglais et que les utilisateurs parlent français, voir également allemand ? Choisir le langage de référence, celui utilisé par les experts du domaine
  37. 37. Avoir des domaines pérennes Les différentes couches Domaine représentent le coeur de métier d’une entreprise. Leur durée de vie est souvent bien plus grande que celle des technologies utilisées. Il se peut même qu’il faille un jour porter ces règles métier sur une autre plateforme, par exemple dans une application mobile supportant un mode déconnecté. Aussi, il est important que l’adhérence des couches domaines au langage et aux outils utilisées soit contenue, afin de pouvoir aisément basculer sur de nouvelles technologies.
  38. 38. Lisez le livre !
  39. 39. Mais... tout le métier est dans un même processus Tout le métier peut appeler tout le métier  ● Tout peut dépendre de tout ● Complexité résultante importante ● Une erreur, même émanant d'une tâche sans importance, peut planter toute l'application (Out Of Memory en Java par exemple).
  40. 40. Event sourcing
  41. 41. The database is a subset of the logs (La base de données contient un sous ensemble des traces) Une base de données peut être utilisée de façon à mettre à jour les données. Autrement dit, si un utilisateur change de nom, on met à jour la ligne correspondante. On parle alors d'« update in place ». Ce faisant, toutefois, on perd l'ancien nom. Et peut être a t on plus d'informations dans les fichiers de logs : valeur du nouveau nom, de l'ancien, date de mise à jour... Au final, alors qu'on a une base de données avec plein de fonctionnalités, une bonne partie des infos se trouvent dans des fichiers textes plus durs à exploiter et souvent non conservés...
  42. 42. Quid du monde réel ? Pas de mise à jour, seulement des événements. Date et données d'un événement ne changent pas. Seuls de nouveaux événements s'ajoutent.
  43. 43. Evénement : date et données Idées : ● stocker les événements ● construire l'état courant à partir des événements
  44. 44. Evénements publiés et abonnements
  45. 45. Exemples d'événements UserAuthenticated(userId, date) ItemAdded(itemId, number, cartId, date) ItemRemoved(itemId, cartId, date) Verbe des événements toujours au passé : il s'agit de faits.
  46. 46. Etat courant dans des vues Une vue : événements agrégés Souscrire aux événements désirés et créer des vues.
  47. 47. Satisfaire exactement le besoin ! ● Duplication des données dans différentes vues ● Données au format consommé
  48. 48. Snapshots (Instantanés) Besoin de reconstruire une vue ? Faire des instantanés (snapshots) : sauvegarde de l'état de la vue à un événement donné 
  49. 49. Event driven architecture (Architecture orientée événements)
  50. 50. L'espace disque n'est plus une limite
  51. 51. Asynchrone donc distribuable Publication/souscription : asynchrone ● Code construit avec possibilité de distribution => montée en charge
  52. 52. Découplage fort ● L'émetteur de l'événement ignore tout des souscripteurs, l'événement est le seul contrat à honorer => piles techniques différentes possibles, ouverture sur le reste du monde
  53. 53. Conservation des événements suite à leur publication ● historique du système ● capacité à rejouer tout ou partie ● consommation décalée possible
  54. 54. En résumé : Événements, distribution (conservation) et vues ● Changements communiqués via publication d'événements ● Événements conservés ● Événements agrégés dans des vues
  55. 55. Retour au Domain Driven Design Événements pour échanger entre contextes bornés Vues pour mieux servir les lectures du domaine Code des contextes vraiment indépendant les uns des autres, voir même les piles techniques Historique
  56. 56. Event Sourcing basé sur les faits, comment gérer les choses à faire ?
  57. 57. CQRS Command And Query Responsibility Segregation (Ségrégation des Responsabilités de Commande et de Requête)
  58. 58. Base de données  = goulet d'étranglement Constat : la base de données est un goulet d'étranglement des performances et de la modélisation
  59. 59. Une base de données peut consommer 80% du CPU pour la gestion des transactions.
  60. 60. Séparer lecture et écriture Écriture (Write side – Command) : une base de données Lecture (Read side - Request) : réplication de la base d'écriture vers une ou plusieurs bases de données
  61. 61. Pourquoi garder un même modèle ? Écriture et lecture séparées : pourquoi garder le même modèle ? Besoins très différents : même modèle implique des compromis
  62. 62. Write Model (Modèle d'écriture) ● traite les commandes ● émet des événements lorsqu'il accepte les commandes ● assure les invariants (en ayant un état)
  63. 63. Inspiration de l'Event Sourcing Les écrites partagent beaucoup avec les événements. Similitudes ● Ecriture à date donnée ● Contiennent des données exprimant une demande Différences ● Peuvent échouer ● S'ils réussissent, déclenchent des événements
  64. 64. Commande Date, données, consommation unique Peut échouer Introduction de la notion de commande : ● Une date ● Une demande exprimée par les données ● Peut réussir ou non ● Consommation unique : un seul service doit décider de son succès ou non.
  65. 65. Granularité fine des changements Changements via des commandes, non des entités : on peut aisément ne changer qu'une valeur, pas besoin de tout transporter.
  66. 66. 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 ou autres)
  67. 67. É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
  68. 68. Eventual consistency (Consistance à terme)
  69. 69. De quoi parle-t-on ? Données anciennes, pas fausses Performances meilleures que du synchrone
  70. 70. Améliorations aisées Vitesse de rafraîchissement Surveillance & ajout de nœuds
  71. 71. Consistance souvent illusoire Écrans non rafraîchis Transactions consécutives Cache divers Systèmes non entièrement transactionnels Niveau d'isolation des transactions baissé pour raisons de performances
  72. 72. Au niveau de l'interface utilisateur Bloquer en attendant les résultats Indiquer l'en cours Combiner les deux...
  73. 73. Initialement… un monolithe ! Tout dans un processus  ● Appels synchrones ● Quid de plusieurs nœuds (performance, 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 ?
  74. 74. Monolithe  = coûts exponentiels avec le temps 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
  75. 75. Système distribué Monolithe Application desktop/mobile Site promotionnel temporaire Web Scale, SaaS Application web ? Haute disponibilité, montée en charge, pérennité, ouverture technologique Facilité de mise en œuvre, court/moyen terme
  76. 76. Choisissez votre poison & amusez vous !
  77. 77. 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 unifying abstraction 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 Explained http://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/
  78. 78. Remerciements Eric Evans, Rich Hickey, Greg Young : penseurs des concepts présentés  Uwe Schäfer (@codesmell) pour les discussions et l'expertise technique Olivier Schneider (@Oli3dfx) pour les discussions et l'aide pour la présentation Sylvain Assemat, pour avoir permis la mise en oeuvre A vous, pour être venu et avoir tenu si longtemps

×