This document discusses Société Générale's experience using Axon Framework to build microservices for their global financing business. It describes how they adopted Axon Framework in 2015 to build a single platform for financing across 4000 users, using domain-driven design and event sourcing principles. Some key benefits noted are improved security, loose coupling between services, and promotion of good software practices like separating business logic from infrastructure. Challenges and lessons learned are also discussed around skills, tooling, event handling, and testing distributed systems.

1. AxonFramework @ Société Générale
Our experience
igor.lovich@sgcib.com

2. A bit of background

3. the business
société générale global financing
~4000 users world wide
bankers, back office, risk
highly regulated activity
user facing applications

4. back in 2015
Legacy Applications
resistant to change
hard to deliver
hard to test

5. back in 2015
goals
one platform for financing
hide IT complexity
intelligent

6. back in 2015
be more agile
deliver value faster
zero downtime
api

7. back in 2015
approach
complex domain  DDD
auditing / as of requirements  eventsourcing
cqrs

8. back in 2015
approach
complex domain  DDD
auditing / as of requirements  eventsourcing
cqrs

9. so after 2 years

10. 25 microservices (3 using Axon)
3 week sprints
some services delivered on demand

11. clear benefits

12. security is easy (er)
single point of entry into the domain
axon provides mechanisms for command interception

13. events everywhere for free (ish)
integration inter service
map internal Axon Events to published

14. promotes loose coupling
send en email  add a new event listener
create a new read model  add a new event listener

15. promotes good DDD practices
separation of business logic from infrastructure
(even better in Axon 3)
avoiding anaemic domain models

16. it is a framework
imposes a certain conformity
Axon annotations help document code

17. deployment
trunk based development with feature toggles
schema changes are code and are easier to “toggle”

18. testing
testing of aggregates is easy with fixtures
fixture.given(event1, event2)
.when(newCommand)
.expectEvents(event3, event4)

19. odds and ends
great documentation
active user community (axonframework@googlegroups)
copying business objects

20. Lessons Learned
(sometimes the hard way)

21. learning curve

22. skills
Eventstore in Oracle + projections in Elasticsearch
Our business analysts have experience in SQL
We could do a relational projection, but…
Datalake
For now XML queries in oracle
NodeJS scripts to query Elasticsearch

23. service registry and cqrs

24. events
keep them small and business oriented
SomethingSavedEvent with 50 fields….

25. tooling and eventstore
theory: eventstore is immutable
practice: production problem !

26. indempotence
distributed eventbus ( rabbitmq @least one semantics)
transfer state not just change

27. race conditions
1 command : n events
distributed eventbus -> multiple instances

28. can i read my eventstore
Continuous Integration !

29. KISS
Lots of toys: Distributed Command Bus, Distributed Event
Handlers, Snapshots , Caches..
Start as simple...
Add complexity when justified

30. Any questions ?