Application monolithique, Client serveur et N-tiers sont des modèles architecturaux du passé. Aujourd'hui on parle d'applications distribuées, de micro-services et d'acteurs. Mais comment implémenter ces nouveaux modèles d'architecture sans y laisser notre peau? Au cours de cette présentation nous verrons comment résoudre le théorème CAP et livrer une application agile qui répondra au besoins présents et futurs de nos clients.

1. Éric
De Carufel
HOW DDD, CQRS AND EVENT
SOURCING CONSTITUTE THE
ARCHITECTURE OF THE FUTURE

2. ©PyxisTechnologiesinc.
BEFORE TALKING ABOUT THE FUTURE
LET'S TALK ABOUT THE PAST

3. ©PyxisTechnologiesinc.
1960 - BATCH PROCESSING / MAINFRAME

4. ©PyxisTechnologiesinc.
1970 - ONLINE TRANSACTION
PROCESSING (OLTP) / SABRE

5. ©PyxisTechnologiesinc.
1980 - DESKTOP PC / LAN

6. ©PyxisTechnologiesinc.
1990 - 3 TIERS / SERVER / INTERNET

7. ©PyxisTechnologiesinc.
2000 - SOA / WEB / WEB SERVICES

8. ©PyxisTechnologiesinc.
2010 - WEB 2.0 / MOBILE / REST

9. ©PyxisTechnologiesinc.
ARCHITECTURE MUST COMMUNICATE
MAJOR IMMUTABLE DESIGN DECISION
VIA UNDERSTANDABLE ABSTRACTIONS

10. ©PyxisTechnologiesinc.
11
MONOLITHIC APPLICATION
Database
Business logic
User interface

11. ©PyxisTechnologiesinc.
12
Database
Business logic
CLIENT/SERVER APPLICATION
User interface
Database
Business logic
User interface

12. ©PyxisTechnologiesinc.
13
User interface
Database
Business logic
N-TIER APPLICATION
User interface
Database
Business logic
Database
Business logic
User interface

13. ©PyxisTechnologiesinc.
14
User interface
Database
Business logic
TYPICAL ARCHITECTURE
User interface
Database
Business Logic
Database
Business logic
User interface

14. ©PyxisTechnologiesinc.
 Each layer depends on another layer
 Usually all layers depends on the same infrastructure
layer
 UI is tightly coupled with the database (read and write)
 Data layer objects often leak all the to UI
 Data structure has big side effect on domain and UI
 Single point of failure (the single database)
 After some time, system like that are too hard to
maintain and they become legacy and get rewritten
(Usually using the same architecture)
WHAT'S WRONG WITH
LAYERED ARCHITECTURE

15. ©PyxisTechnologiesinc.
SIMPLE DATA MODEL

16. ©PyxisTechnologiesinc.
ADDING NEW FEATURES

17. ©PyxisTechnologiesinc.
Doesn't easily allow Domain Driven Design
(DDD) concept
Usually works with CRUD
This reflect to the UI when a user must know the
data structure to make changes
The system doesn't capture user intention
How to implement…
Auditing / Logging / Traceability?
Reporting?
Distributed data?
DATA DRIVEN ARCHITECTURE

18. ©PyxisTechnologiesinc.
COMPLETED PRODUCT

19. ©PyxisTechnologiesinc.
EVOLUTION…?

20. ©PyxisTechnologiesinc.
CAP THEOREM IN DISTRIBUTED SYSTEM
Availability
PartitioningConsistency
A
C P
CA AP
CP
SQL Server
Oracle
MongoDB
Redis
Cassandra
CouchDB

21. ©PyxisTechnologiesinc.
22
UI DataBusiness
Request
Command Write
Read
TYPICAL APPLICATION
OPTIMIZE READ WITH INDEXES
INDEXES AS NEGATIVE PERFORMANCE ON WRITES

22. ©PyxisTechnologiesinc.
23
UI DataBusiness
Request
Command Write
Read
WORKING WITH STALE DATA
20ms 100ms
20ms 100ms
100ms
20ms
Approx. 360ms. + User thinking
1000+
ms.

23. ©PyxisTechnologiesinc.
HOW TO BUILD PERFORMANT
(DISTRIBUTED) SYSTEM THAT TAKE
ACCOUNT STALE DATA AND IS EASY TO
MAINTAIN AND EVOLVE?

24. ©PyxisTechnologiesinc.
Domain Objects
Entity
Value object
Aggregate (root)
Infrastructure
Service
Repository
Factory
DDD TERMINOLOGY

25. ©PyxisTechnologiesinc.
AN ENTITY IS NOT DEFINED BY ITS
ATTRIBUTES. IT IS ONLY IDENTIFIYABLE BY A
UNIQUE IDENTITFIER. IT CAN EVOLVE
THROUGH TIME AND CAN BE ASSOCIATED
WITH OTHER OBJECTS
ENTITY

26. ©PyxisTechnologiesinc.
A VALUE OBJECT IS DEFINED BAY ALL ITS
ATTRIBUTES. IT CAN BE PASS ONLY BY
IMMUTABLE COPY OF ITSELF. ANY CHANGE
WOULD RESULT IN A NEW AND UNRELATED
OBJECT.
CONTEXT MATTER!
VALUE OBJECT

27. ©PyxisTechnologiesinc.
AN AGGREGATE IS A CLUSTER OF ENTITY
AND VALUE OBJECT THAT ARE CLOSELY
RELATED.
(ONE ENTITY IN THAT CLUSTER ACT AS A
ROOT OBJECT AND IS THE ONLY ONE THAT
CAN BE REFERENCED FROM THE OUTSIDE)
AGGREGATE (ROOT)

28. ©PyxisTechnologiesinc.
SERVICE IS A STATELESS OBJECT THAT USE
DOMAIN OBJECT AS INPUT AND OUTPUT.
SERVICE OPERATION SHOULD NOT BE
SOMETHING THAT BELONG TO ENTITY OR
VALUE OBJECT.
SERVICE

29. ©PyxisTechnologiesinc.
A (DOMAIN) REPOSITORY ACT AS AN
ABSTRACTION BETWEEN AN AGGREGATE
AND ITS PERSISTENCE. IT TAKE CARE OF
RECREATING AN INSTANCE FROM ONE OR
MANY PERSISTENCE SOURCES.
REPOSITORY

30. ©PyxisTechnologiesinc.
A FACTORY ONLY CREATE OBJECT IN A
CONSISTENT STATE WITH ALL INVARIANTS
SATISFIED. THIS CONSTRUCTION SHOULD BE
AN ATOMIC PROCESS.
FACTORY

31. ©PyxisTechnologiesinc.
32
SEPARATE READ FROM WRITE
UI Write
model
Domain
Command Write
Commands - change data
UI Read
model
Query
Request Read
Queries - read data (no side effect)

32. ©PyxisTechnologiesinc.
33
WE NEED TO SYNCHRONIZE
WRITE AND READ MODELS
UI Write
model
Domain
Command Write
Commands - change data
UI Read
model
Query
Request Read
Queries - read data (no side effect)

33. ©PyxisTechnologiesinc.
DEFINE SOMETHING THAT HAPPENED
IN THE PASS. IT IS IMMUTABLE. IT
MUTATE THE STATE OF AN AGGREGATE
AND KEEP IT COHERENT.
IT IS SEQUENTIAL AND SERIALIZABLE.
DOMAIN EVENT

34. ©PyxisTechnologiesinc.
 Invite the right people
 People that know the questions
 People that know the answers
 Provide unlimited modeling space
 Explore and define Domain Events
 Relevant to business
 Placed in order
 Explore origin of Domain Events
 User action are commands
 Time may trigger some events
 Group events in aggregates
 Derive entities and value objects
EVENT STORMING

35. ©PyxisTechnologiesinc.
EVENT SOURCING
AGGREGATE
Order
Created
Product
Added
Product
Added
Product
Removed
Product
Added
Order
Completed
AN AGGREGATE HOLDS HIS OWN DOMAIN
EVENTS AND BUILD ITS STATE FROM THEM

36. ©PyxisTechnologiesinc.
MANY PERSPECTIVES ON DATA
Customer
Product
Cost
Markup
Quantity
Price
Quantity Ordered
Name
Buyers Inventory
Manager
Sales
Rep.

37. ©PyxisTechnologiesinc.
MANY PERSPECTIVES ON DATA
Buyers Inventory
Manager
Product
Quantity
ProductId
Product
Cost
Makup
ProductId
Product
Price
Quantity Ordered
Name
ProductId
Shared Entity Identity
Sales
Rep.
Bounded Context

38. ©PyxisTechnologiesinc.
PUTTING IT ALL TOGETHER
Client
Commands
Command
Bus
Sends
Command
Handlers
Modify
Repositories
Read Write
Data
store
Event
Bus
Command Services
Event Handlers
Events
Denormalized
Read
store
Query HandlersQuery Results
Queries
Query Services
Events
Domain
UI
adaptation from Jeppe Cramon

39. ©PyxisTechnologiesinc.
DO NOT DESIGN FOR LOCALITY AND TRY TO
DISTRIBUTE
DESIGN FOR DISTRIBUTION, TAKE ADVANTAGE
OF LOCALITY

40. ©PyxisTechnologiesinc.
DO START WITH SYNCHRONOUS CALLS AND
TRY TO MAKE THEM ASYNCHRONOUS
START WITH ASYNCHRONOUS CALLS AND
SYNCHRONIZE THE RESPONSES

41. QUESTIONS