Si vous avez -500 euros sur votre compte en banque, qu’est-ce qui vous intéresse ? De savoir que vous êtes à découvert de 500 euros (état de votre compte) ou qu’un prélèvement a été fait la veille d’un montant de 2500 euros (évènement) ? Avec tous les évènements qui ont eu lieu sur votre compte, vous pouvez en déduire l’état. Avec son état, c’est compliqué de retrouver les évènements qui en sont la cause. Alors pourquoi programmons nous en nous basant sur des états au lieu de nous baser sur des évènements ? Nous verrons donc comment remettre les évènements au centre de nos réflexions, d’un point de vue technique et fonctionnel. Nous parlerons pour cela d’Event Storming, de CQRS, d’Event Sourcing et de DDD.

1. Pourquoi les évènements
sont importants?
@ouarzy

2. http://www.ouarzy.com
@ouarzy

3. Data Driven / CRUD
@ouarzy
--------------
Nice
User Interface
(FORM)
------------
DATA
(DB)
ORM

4. Data Driven / CRUD
Mais au fait pourquoi on fait du logiciel?
Automatiser des processus pour aider un métier

5. Data Driven / CRUD
@ouarzy
--------------
Nice
User Interface
(FORM)
------------
DATA
(DB)
ORM
METIER?

6. Pro Tip
Accumuler des couches n’est pas la solution
@ouarzy

7. Architecture en couche
--------------
Nice
User Interface
(FORM)
------------
DATA
(DB)
DATA ACCESS (ORM)
METIER
@ouarzy

8. Se centrer sur le métier
Domain DesignDriven
@ouarzy

9. Domain Driven
Mais comment mettre le métier au centre?
@ouarzy

10. Protéger la couche métier
@ouarzy
METIER
--------------
Nice
User Interface
(FORM)
------------
DATA
(DB)

11. @ouarzy
Mieux: avoir une approche
évènementielle

12. Comment?
Avec une approche évènementielleConstruire un logiciel
@ouarzy
Alors, on code
quoi?

13. Analyse du problème
@ouarzy

14. Event Storming
@ouarzy
« The amount of energy to
refute bulllshit is an order of
magnitude higher than to
produce it »
- @ziobrando

15. @ouarzy

16. Le but?
Juste un exemple parmi
d’autres…
Un exemple parmi d’autres
@ouarzy

17. Ubiquitous Language
@ouarzy

18. Partage de connaissance
Compréhension partagée du problème qui justifie
cette solution
@ouarzy
«It’s developer’s
understanding, not your
knowledge that become
software! »
- @ziobrando

19. Et le code dans tout ça?
@ouarzy
Sinon moi je veux
bien livrer des
post-it…

20. Event Sourcing
Inspiré de Jérémie Chassaing
Decide
Apply
Aggregate
Commands Events
Decision
Projection
Store
Side
Effects
Outside
World
@ouarzy

21. CQRS
Inspiré de Greg Young
Commands
Aggregates
Events
Projections--------------
Nice
User Interface
------------
Outside
Real
World
Com
m
and
Query
@ouarzy

22. Changement de mentalité
Les limites?
@ouarzy

23. Plus difficile dans le code de suivre un cas d’utilisation
Les limites?
@ouarzy
Runtime
Artifact
Decision

24. Les idée reçues
C’est très complexe à implémenter
C’est utile seulement pour Google
@ouarzy

25. Les idée reçues
C’est pas performant
C’est que pour la performance
@ouarzy

26. Des architectures parmi d’autres
@ouarzy
Le but?
Juste un exemple parmi
d’autres…

27. Aligner le code et le métier
Montrez votre code aux experts métier…
…Ils ne comprennent pas?
Vous êtes le problème.
@ouarzy

28. Car le métier va évoluer
Un code simple à modifier
No time for testing death spiral
Pressure
TestingErrors + -
+
+-
-
@ouarzy

29. Une vraie équipe
Chef de projet
Expert métier
Utilisateur
Développeur
Développeur
Testeur

30. En résumé
Les évènements sont importants pour être plus proche du métier
Dans l’analyse du problème
Et dans l’implémentation de la solution
Juste des exemples…

31. @ouarzy
Merci
http://www.ouarzy.com

32. References
https://leanpub.com/livingdocumentationLiving Documentation
Event Storming
@cyriux
https://leanpub.com/introducing_eventstorming
@ziobrando
Domain Driven Design:Tackling Complexity In The
Heart of Software@ericevans0
@ScottMillett
Patterns, Principles and Practices of DDD

33. References
@thinkb4coding
@gregyoung
https://goodenoughsoftware.net/
http://thinkbeforecoding.com/
@CarloPescio
http://www.physicsofsoftware.com/