La simplicité comme moyen d'être performant, résilient et de réduire le Time To Market. Il y a 1 an et demi, la Société Générale a décidé de construire un nouveau service de vente électronique de nos produits financiers. Les contraintes étaient claires : "le système sera performant, auditable, résilient et développé de manière à avoir un Time To Market court". Une seule solution s'imposait à nous : faire simple, très simple ! Ainsi à travers cette présentation, nous vous raconterons notre quête de simplicité. Vous verrez ainsi que notre stack technique ne contient quasiment aucun framework, juste quelques bibliothèques utiles ou indispensables. Notre code se structure autour de quelques principes : l'Event Sourcing, un peu de Domain Driven Design et une discipline de fer en matière de qualité et de tests automatisés (BDD for the win!).

1. Construire le SI de demain
REX Société Générale
La simplicité comme moyen d'être
performant, résilient
et de réduire le Time To Market

2. Marie-Laure
Thuret
@mlthuret
Développeur
chez
Clément
Héliou
@c_heliou
Développeur
chez
Thierry
Abaléa
@ThierryAbalea
Tech Lead
à la
Société
Générale

7. Palladium

9. Commodity
Trading Company

10. Today
Hedging
Commodity
Trading Company

11. Commodity
Trading Company
Few Months Later
Hedging
Physical Delivery

13. Sales PersonCustomer Trader
Booking
Exchanges

14. Automatize
the processus

15. OrchestratorCustomer ExchangesPricer
Booking
Hedger
Trading Limit
Margin

17. The Constraints
Reliability / Resilience Performance
Productivity / Time To Market

18. Our Solution
Simplicity

19. Simple ≠ Easy

20. Choices are
business-oriented

21. Functional and
Code
Reduce the impedance between
Our Goal

22. Orchestration
Let’s take an example with
our main component

26. Event Sourcing

27. « Capture all changes to an
application state as a
sequence of events »
Martin Fowler

28. Date Money Out Money In
2015/05/14 100
2015/05/14 -20
2015/05/16 -30
2015/05/24 380
2015/06/01 -70
Total -120 480
Balance 360

29. WithdrawalPerformed
accountId: 9387
amount: 30€
BankAccount
id: 9387
balance: 0€
WithdrawalPerformed
accountId: 9387
amount: 20€
DepositPerformed
accountId: 9387
amount: 100€
BankAccount
id: 9387
balance: 50€
BankAccount
id: 9387
balance: 100€
BankAccount
id: 9387
balance: 80€
Inspired by B. Reitzammer & J. Seitz - http://ookami86.github.io/event-sourcing-in-practice
Apply to
Apply to
Apply to
Produces
Produces
Produces

30. J. Chassaing - http://thinkbeforecoding.com/post/2014/01/04/Event-Sourcing.-Draw-it

31. BankAccount
id: 9387
balance: 0€
WithdrawalPerforme
accountId: 9387
amount: 20€
DepositPerformed
accountId: 9387
amount: 100€
BankAccount
id: 9387
balance: 100€
Bug
Inspired by B. Reitzammer & J. Seitz - http://ookami86.github.io/event-sourcing-in-practice
Apply to
Apply to
Produces
Produces

32. WithdrawalPerformed
accountId: 9387
amount: 30€
BankAccount
id: 9387
balance: 0€
WithdrawalPerformed
accountId: 9387
amount: 20€
DepositPerformed
accountId: 9387
amount: 100€
BankAccount
id: 9387
balance: 100€
BankAccount
id: 9387
balance: 70€
Inspired by B. Reitzammer & J. Seitz - http://ookami86.github.io/event-sourcing-in-practice
Apply to
Apply to
Produces
Produces

33. Domain Driven Design

34. « DDD is about designing
software based on models
of the underlying
(business) domain »
Martin Fowler

35. Ubiquitous
Language
RepositoryAggregate Root
Entity
Value Object

36. Durable business
model
Extensibility
Clean Architecture
Solid Responsibility Segregation

37. Using Event Sourcing
and DDD concepts in
Multiplus

38. Multiplus
Business
Logic
ReceiveQuote
{command}
QuoteReceived
{event}
QuoteForwarded
{event}
Customer
EventBus
QuoteForwardedHandler
{handler}
Quote
Requestin Quoting
QuoteReceived
{event}
QuoteReceived
{event}
ForwardQuote
{action}

39. Transaction
{aggregate root}
Pricing
{entity}
Execution
{entity}
Orchestration
{entity}
ReceiveQuote
{command/value object}
quoteRequestId: 4563
price: 100€
QuoteReceived
{event/value object}
accountId: 4563
price: 110€
- Multiplus Business Logic -

40. What we’ve learned

41. Be awareof
Command Sourcing

42. Multiplus
Business
Logic
ReceiveQuote
{command}
quoteRequestId: 4563
price: 100€
QuoteForwarded
{event}
accountId: 4563
price: 101€
Multiplus
Business
Logic
ReceiveQuote
{command}
quoteRequestId: 4563
price: 100€
QuoteForwarded
{event}
accountId: 4563
price: 102€
2015/06/01 Margin: 1%
2015/11/01 Margin: 2%

44. Multiplus
Business
Logic
ReceiveQuote
{command}
QuoteForwarded
{event}
Customer
EventBus
QuoteForwardedHandler
{handler}
{Quote n° 65746}
{Quote n° 65746} ??
QuoteReceived
{event}
ForwardQuote
{action}

45. Multiplus
Business
Logic
ReceiveQuote
{command}
QuoteForwarded
{event}
Customer
EventBus
QuoteForwardedHandler
{handler}
Customer
gateway
{Quote n° 65746}
{Quote n° 65746}
QuoteReceived
{event}
ForwardQuote
{action}

46. Store the events
produced by the
Decide function

47. Multiplus
Business
Logic
ReceiveQuote
{command}
quoteRequestId: 4563
price: 100€
QuoteForwarded
{event}
accountId: 4563
price: 101€
Multiplus
Business
Logic
2015/06/01 Margin: 1%
2015/11/01 Margin: 2%
QuoteForwarded
{event}
accountId: 4563
price: 101€

48. Multiplus
Business
Logic
ReceiveQuote
{command}
QuoteForwarded
{event}
Customer
EventBus
QuoteForwardedHandler
{handler}
QuoteReceived
{event}
ForwardQuote
{action}

49. It’s all in the past !

50. Date Money Out Money In
2015/05/14 100
2015/05/14 -20
2015/05/16 -30
2015/05/24 30
2015/06/01 -70
Total -120 130
Balance 10

51. Behavior Driven
Development
Conversation
Collaboration
Specifications By Examples
Three Amigos
Automation
Ubiquitous Language

52. deliver
theright
software

53. Your
documentation
will become
alive

54. you
will
new comers
thank

55. you
will
new comers
thank
… but you’ll enjoy it too !

56. warning

57. doing BDD right
easy
is not

58. BDD
Common Issues
Business and developper
faces collaboration difficulties
Mess with the
scenario writing
Automation Nightmare

59. BDD
Common Issues
Business and developper
faces collaboration difficulties
Mess with the
scenario
writing
Automation Nightmare

60. our
complex
application
are
often

61. we tend to let
everywhere
business rules
being dispatch

62. … making them
hard to test

63. Hexagonal
Architecture
the onion architecture
the clean architecture
ports and adapters

65. Advantages
Testability Flexibility
Business Centric

66. domain driven
app structure

67. that’s not
enough !

68. use different
granularity
business scenarios
when expressing your
levels

69. Given a quantity value of 1000 in G
When the quantity is converted in OZ
Then the converted quantity is 32.1507 OZ
Given a quote request with a way BUY
And the credit check request has been sent
When the credit check response is in error
Then the pricer does not receive a quote request
And the platform quote status is REJECTED
Given an authorized product type
When the customer sends the rfs
Then the pricer receives the rfs
When the pricer sends a quote
Then the customer receives the quote
Workflow
Feature
Unit

70. « l’enfer c’est les
autres »
Jean-Paul Sartre

71. at
any time
business validation

73. steroids
integration testing
on

74. care about
the contract
between your app and another

75. avoid
accidental
complexity

76. there’s always
implicit
a schema
even if it’s

77. Hexagonal
Architecture
DDD
Event Sourcing
BDD
State Machine

78. Hexagonal
Architecture
Java
DDD
Event Sourcing
BDD
State Machine

79. Hexagonal
Architecture
DaggerJava
DDD
Event Sourcing
BDD
State Machine

80. Hexagonal
Architecture
DaggerJava
Guava
DDD
Event Sourcing
BDD
State Machine

81. Our architecture
is easy to deploy !

82. Simple

83. Simple
No More Technologies Than Required

84. Simple
No More Technologies Than Required
Business Centric

85. Simple
No More Technologies Than Required
Business Centric
Code Understanding is Key

86. Simple
No More Technologies Than Required
Business Centric
CourageCode Understanding is Key

87. Any Questions ?