CQRS with event sourcing; we’ve been living it for the past 3 years with 3 micro services in production using the Axon Framework

1. MONOLITH TO SERVICES
History of a pattern based transition
Patrice Fricard - TechnicalArchitect

2. MONOLITH TO SERVICE: THE GENESIS
DAY 1:
A simple business requirement is
developed with different layer
DAY 2:
We add new features keeping the
good practices
DAY 5:
The monster is born
-hard to enhance functionally
-hard to test
-hard to upgrade technically
DAY 3:
We add more and more features
coupling layers
DAY 4:
We take shortcuts to achieve go
faster: no more layers
Any resemblance to real projects is purely coincidental.

3. MONOLITH TO SERVICE: PREPARATION PHASE
HOW TO HUNT THE BEAST
« every battle is won before it is fought »
• KNOW YOUR ENEMY
• PREPARE YOUR WEAPONS
• APPLY YOUR STRATEGY

4. Texte ici
THE CLOUD PATTERNS: THE MICROSERVICES ALLIES
Ambassador Valet Key
Throttling
Strangler
Command and Query Responsibility Segregation (CQRS)
Gateway Aggregation
Gateway Offloading
Gateway Routing
Gatekeeper
Health Endpoint Monitoring
Federated Identity
External Configuration StoreIndex Table
Leader Election
Materialized View
Queue-Based Load Leveling
Priority Queue
Pipes and Filters
Static Content Hosting
Sidecar
Scheduler Agent Supervisor
Sharding
Event Sourcing
Compute Resource Consolidation
Competing Consumers
Compensating Transaction
Circuit Breaker
Cache-Aside
Bulkhead
Backends for Frontends
Anti-corruption Layer
Retry
Microsoft Cloud Design Patterns

5. MONOLITH TO SERVICE: STRANGLER PATTERN
STRANGLE THE BEAST
• Stop digging / Starving the beast
• Split front end & back end
• Extract Modules
STRANGLER PATTERN
« Incrementally migrate a legacy system by gradually replacing specific pieces of functionality
with new applications and services. As features from the legacy system are replaced, the new
system eventually replaces all of the old system's features, strangling the old system and
allowing you to decommission it. »
https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler
https://www.martinfowler.com/bliki/StranglerApplication.html

6. MONOLITH TO SERVICE ANTI-CORRUPTION LAYER PATTERN
ISOLATE THE BEAST
Put your legacy in a well defined zone
• ANTI -CORRUPTION LAYER PATERN
• between legacy and new services
• between legacy and downstream application

7. Texte ici
ASK YOU THE RIGHT QUESTION NOW
MONOLITH TO SERVICE: TRANSITION WAY
• HAVE WE AUTONOMOUS MODULES?
• Yes, so we can extract & refactor code in a service
• IS THE DATA MODEL FUNCTIONALLY CONSISTENT?
• No, you will have to send data to new service and legacy :(
• IS THE LEGACY FEEDING MULTIPLE DOWNSTREAM APPLICATION?
• Yes, rewrite with synchronization by replication
• No, rewrite with synchronization by aggregation

8. Texte ici
DETAILS OF THE « SYNCHRONISATION BY AGGREGATION »
MONOLITH TO SERVICE: TRANSITION WAY
UI
Gateway
Routing
Legacy
Gateway
Aggregation
New
Servic
e
• USE OF ONE AGGREGATION GATEWAY and ONE ROUTING
GATEWAY
• GOOD SCENARIO
• no data duplication
• separation of responsibility

9. Texte ici
DETAILS OF THE « SYNCHRONISATION BY REPLICATION »
MONOLITH TO SERVICE: TRANSITION WAY
UI
Gateway
Routing
Legacy
New
Servic
e
• USE OF ONE ROUTING GATEWAY
• WE DIDN’T HAVE TO MODIFY THE DOWNSTREAM FEEDING

10. Texte ici
DETAILS OF THE DOUBLE FEEDING SCENARIO
MONOLITH TO SERVICE: TRANSITION WAY
UI
Gateway
Aggregation
& Routing
Legacy
Gateway
Aggregation
New
Servic
e
• USE OF A DOUBLE AGGREGATION GATEWAY
• TECHNICALLY COMPLEX
• WE DID’NT HAVE TO TOUCH THE LEGACY

11. Texte ici
INSURE THE DATA CONSISTENCY
MONOLITH TO SERVICE: TRANSITION WAY
UI
Gateway
Aggregation
& Routing
Legacy
Gateway
Aggregation
New
Servic
e
• SIDECAR PATTERN
• we extended this pattern through a messaging bus
• but you can host it directly with your gatewaySIDECAR
Consistency Check

12. Strangler is the key pattern
Ask you the 3 questions to find the best way
Not modifying the legacy is (y)our challenge