DDD, CQRS et Event Sourcing :
quand coder propre ne suffit plus
Joseph Pachod
https://twitter.com/joeclueless
DISCLAIMERS
Applications partielles
Juste des approches
Je n'ai eu fait que des applications partielles des
idées présenté...
Coder propre nécessaire mais...
Coder propre : plein de règles applicables localement
(cf http://www.slideshare.net/cluele...
Capture du métier ?
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...
Layered architecture
(Architecture en couches)
Interface utilisateur, application,
domaine, infra
La couche application :
...
Entities, value objects, stateless
services…
(Entités, objets valeurs et services sans état…)
Objets valeurs : immuables, ...
Aggregates
(Agrégats)
Il arrive souvent qu'une même mise à jour implique
plusieurs entités.
A défaut d'une notion engloban...
Agrégat :
- une entité racine, seule référence persistante
possible du reste du monde vers l'agrégat
-- peut contenir des ...
Repositories
(Entrepôts)
Entrepôt :
- unique façon d'obtenir des instances d'agrégat
=> pas d'accès direct aux entités, de...
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é)
Une équipe peut travailler sur plusieurs contextes, un
contexte ne peut être manipulé que...
Context map
(Carte de contexte)
Identifie les différents contextes bornés et leurs
relations.
Les noms des contextes font ...
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)
...
En résumé
En résumé
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
(Cœur de domaine avec sa vision)
Plus de ressources, les meilleurs développeurs...
Remarques & avis personnel
Modélisation « tactique »
au choix de l'équipe
Avoir des contextes pérennes
Cas des Frenchies
(et autres non anglophones)
Lisez le livre !
Mais...
tout le métier est dans un même
processus
« techniquement » tout le métier peut appeler tout le
métier : possibili...
Event sourcing
The database is a subset of the
logs.
(La base de données contient un sous
ensemble des traces.)
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 vue ...
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 ...
Le temps CPU d'un serveur de base
de données peut être utilisé à 80 %
par la gestion des transactions.
Dixit Rich Hickey, ...
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 :...
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 ...
Write Model
(Modèle d'écriture)
● traite les commandes
● émet des événements lorsqu'il accepte les
commandes
● assure les ...
Granularité fine des changements
Changements via des commandes, plus des entités :
on peut aisément ne changer qu'une vale...
Tasks focused UI
(Interface utilisateur centrée sur les tâches)
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...
Consistance à terme
Consistance souvent illusoire
Écrans non rafraîchis
Transactions consécutives
Cache divers
Systèmes non entièrement transa...
De quoi parle-t-on ?
Données anciennes, pas fausses
Performances meilleures que du synchrone
Au niveau de l'interface utilisateur
Bloquer en attendant les résultats
Indiquer l'en cours
Combiner les deux...
Améliorations aisées
Vitesse de rafraîchissement
Surveillance & ajout de nœuds
Contrairement au synchrone, l'asynchrone of...
Initialement…
un monolithe !
Tout dans un processus
● Appels synchrones
● Quid de plusieurs nœuds (performance,
redondance...
Monolithe 
=
coûts exponentiels avec le temps
Montées en charge difficile
● Du nombre d'utilisateur
● Du nombre de fonctio...
Self-contained Systems (SCS)
&
Micro services
Un SCS est détenu par une équipe et est une entité
logique autonome, avec sa...
CONCLUSION
Système distribué
Monolithe
Application desktop/mobile
Site promotionnel temporaire
Web Scale, SaaS
Application web ?
Haut...
Choisissez votre poison
&
amusez vous !
Pour avancer concrètement
Frameworks/librairies souvent trop générales
Approfondir via des implémentations d'event bus
(Ka...
Pour approfondir
● Talks de Rich Hickey http://www.infoq.com/author/Rich-Hickey
● Talks de Greg Young http://www.infoq.com...
Remerciements
Les personnes citées auparavant
Uwe Schäfer (@codesmell) pour les discussions et l'expertise technique
Olivi...
DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant
DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant
Prochain SlideShare
Chargement dans…5
×

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

1 414 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
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 414
Sur SlideShare
0
Issues des intégrations
0
Intégrations
24
Actions
Partages
0
Téléchargements
18
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. DDD, CQRS et Event Sourcing : quand coder propre ne suffit plus Joseph Pachod https://twitter.com/joeclueless
  2. 2. DISCLAIMERS Applications partielles Juste des approches Je n'ai eu fait que des applications partielles des idées présentées ● Framework closed source d'Event Sourcing ● DDD => pas de projet « from scratch » jusqu'ici Juste 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 des produits/frameworks existants) => de la matière à penser !
  3. 3. Coder propre nécessaire mais... Coder propre : plein de règles applicables localement (cf http://www.slideshare.net/cluelessjoe/coder-propre ), bien moins à l'échelle d'une application. Comment capturer le métier ? ● couches techniques souvent plus simples à organiser ● Conservation des connaissances métier de façon pérenne ? Tout le métier peut appeler tout le métier ● Tout peut dépendre de tout ● Une partie, même mineure, cassée peut casser toute l'application ● Complexité résultante importante
  4. 4. Capture du métier ?
  5. 5. DDD - Domain-Driven Design (Conception dirigée par le domaine) Pas un framework ni une méthodo, plutôt une approche
  6. 6. 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.
  7. 7. Pré requis Travail itératif Accès direct aux experts du domaine Métier complexe
  8. 8. 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.
  9. 9. 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
  10. 10. 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.
  11. 11. Mise en œuvre "tactique" Eric Evans parle « tactique » Mise en œuvre reprise parfois au pied de la lettre, notamment en .Net
  12. 12. Layered architecture (Architecture en couches) Interface 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, pas d'état demeurant au-delà. => la couche domaine est le coeur d'une application métier, tout le métier doit s'y trouver
  13. 13. Entities, value objects, stateless services… (Entités, objets valeurs et services sans état…) Objets valeurs : immuables, pas d'identité, égalité définie par les valeurs de leur champs. Services : 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.
  14. 14. Aggregates (Agrégats) Il arrive souvent qu'une même mise à jour implique plusieurs entités. A défaut d'une notion englobante, on en vient à créer des transactions en base de données qui s'assurent elles de préserver les contraintes de modélisation liant ces entités. DDD veut expliciter au niveau du code ces contraintes et introduit donc la notion d'Agrégat, un regroupement d'entités constituant un tout logique. L'entité la plus significative d'un agrégat est appelé Root entity et centralise les actions de modification, ce qui lui permet d'assurer explicitement les contraintes métier.
  15. 15. 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 Dans l'exemple ci dessus, passer en pneus hiver se fait via l'entité racine Car. Elle peut alors s'assurer que 2 pneus avant, ou 2 arrière ou 4 pneus sont bien montés.
  16. 16. Repositories (Entrepôts) Entrepôt : - unique façon d'obtenir des instances d'agrégat => pas d'accès direct aux entités, de granularité trop fine - 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 et refactoring
  17. 17. 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.
  18. 18. 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 ?
  19. 19. Niveau stratégique
  20. 20. Bounded context (Contexte borné) Une équipe peut travailler sur plusieurs contextes, un contexte ne peut être manipulé que par une équipe. 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.
  21. 21. 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
  22. 22. Anti corruption layer (Couche anti corruption)
  23. 23. Shared kernel (Noyau partagé) Customer/supplier (Client-fournisseur) Anti corruption layer (Couche anti corruption) Conformist (Conformiste) Separate ways (Chemins séparés) Collaboration + -
  24. 24. Published langage (Langage publié) Open host service (Service hôte ouvert) Anti corruption layer (Couche anti corruption) Ouverture + -
  25. 25. En résumé En résumé
  26. 26. 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.
  27. 27. Core domain with a vision statement (Cœur de domaine avec sa vision) Plus de ressources, les meilleurs développeurs...
  28. 28. Remarques & avis personnel
  29. 29. Modélisation « tactique » au choix de l'équipe
  30. 30. Avoir des contextes pérennes
  31. 31. Cas des Frenchies (et autres non anglophones)
  32. 32. Lisez le livre !
  33. 33. Mais... tout le métier est dans un même processus « techniquement » tout le métier peut appeler tout le métier : possibilité d'interférer avec du code d'autres contextes Une erreur, même émanant d'une tâche sans importance, peut arrêter toute l'application (Out Of Memory en Java par exemple).
  34. 34. Event sourcing
  35. 35. The database is a subset of the logs. (La base de données contient un sous ensemble des traces.)
  36. 36. 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.
  37. 37. Evénement : date et données Idées : ● stocker les événements ● construire l'état courant à partir des événements
  38. 38. Evénements publiés et abonnements
  39. 39. 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.
  40. 40. Etat courant dans des vues Une vue : événements agrégés Souscrire aux événements désirés et créer des vues.
  41. 41. Satisfaire exactement le besoin ! ● Duplication des données dans différentes vues ● Données au format consommé
  42. 42. Snapshots Instantanés Besoin de reconstruire une vue ? Faire des instantanés (snapshots) : sauvegarde de l'état de la vue à un événement donné
  43. 43. Event driven architecture (Architecture orientée événements)
  44. 44. L'espace disque n'est plus une limite
  45. 45. Asynchrone donc distribuable Publication/souscription : asynchrone ● Code construit avec possibilité de distribution => montée en charge
  46. 46. 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
  47. 47. Conservation des événements suite à leur publication ● historique du système ● capacité à rejouer tout ou partie ● consommation décalée possible
  48. 48. 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
  49. 49. 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
  50. 50. Event Sourcing basé sur les faits, comment gérer les choses à faire ?
  51. 51. CQRS - Command And Query Responsibility Segregation (Ségrégation des Responsabilités de Commande et de Requête)
  52. 52. 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
  53. 53. Le temps CPU d'un serveur de base de données peut être utilisé à 80 % par la gestion des transactions. Dixit Rich Hickey, de mémoire.
  54. 54. 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
  55. 55. 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
  56. 56. 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
  57. 57. 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.
  58. 58. 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)
  59. 59. Granularité fine des changements Changements via des commandes, plus des entités : on peut aisément ne changer qu'une valeur, pas besoin de tout transporter.
  60. 60. Tasks focused UI (Interface utilisateur centrée sur les tâches)
  61. 61. 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)
  62. 62. É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
  63. 63. Consistance à terme
  64. 64. Consistance souvent illusoire Écrans non rafraîchis Transactions consécutives Cache divers Systèmes non entièrement transactionnels Niveau de transaction baissé pour raisons de performances
  65. 65. De quoi parle-t-on ? Données anciennes, pas fausses Performances meilleures que du synchrone
  66. 66. Au niveau de l'interface utilisateur Bloquer en attendant les résultats Indiquer l'en cours Combiner les deux...
  67. 67. Améliorations aisées Vitesse de rafraîchissement Surveillance & ajout de nœuds Contrairement au synchrone, l'asynchrone offre de nombreuses possibilités de pour supporter la montée en charge : - rafraichir des vues non pas à chaque événement mais toutes les 5 secondes par exemple - surveillance aisée de la charge de part les événements en attente de traitement - possibilité d'ajouter des nœuds aisées pour des vues très sollicitées
  68. 68. 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 ?
  69. 69. 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
  70. 70. Self-contained Systems (SCS) & Micro services Un SCS est détenu par une équipe et est une entité logique autonome, avec sa propre IHM, sa propre logique et ses propres données. Son code métier ne doit pas être partagé avec un autre SCS. Les communications avec les tiers doivent être asynchrones. Un micro service est une unité plus petite qu'une SCS. Il ne doit faire qu'une chose : stockage de données, règles métier ou IHM par exemple. La communication synchrone avec d'autres microservices est possible. Pour netflix, acteur majeur du web, 1000 micro services font sens. Pour un acteur plus petit, des SCS semblent préférable en 1ere approche.
  71. 71. CONCLUSION
  72. 72. 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
  73. 73. Choisissez votre poison & amusez vous !
  74. 74. Pour avancer concrètement Frameworks/librairies souvent trop générales Approfondir via des implémentations d'event bus (Kafka https://kafka.apache.org/)
  75. 75. 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-kn ow-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/ ● Self-Contained Systems https://www.innoq.com/en/links/self-contained-systems-infodeck/ ● Coder Propre http://www.slideshare.net/cluelessjoe/coder-propre
  76. 76. Remerciements Les personnes citées auparavant Uwe Schäfer (@codesmell) pour les discussions et l'expertise technique Olivier Schneider (@Oli3dfx) pour les discussions et l'aide pour la présentation Pierre-Nicolas Horn, pour l'aide pour la présentation A vous, pour être venu et avoir tenu si longtemps

×