CQRS (Command Query Responsibility Segregation) als Architektur-Pattern sieht vor, dass lesende (Queries) und schreibende Zugriffe (Commands) in getrennten Subsystemen auf unterschiedlichen Modellen realisiert werden. Während Commands meist asynchron und transaktional angestoßen werden, arbeiten Queries mit denormalisierten Views auf “eventual consistent” Daten. Ziel ist eine hoch skalierbare, hoch performante und sichere Plattform. Was sich zunächst einmal nach zusätzlichem Aufwand anhört, bringt in der Praxis eine Menge Vorteile mit sich. Die Session zeigt die wesentlichen Ideen von CQRS auf und demonstriert anhand eines praktischen Beispiels die Vorteile dieses Ansatzes im Kontext von Web APIs.

1. C Q R S
Der etwas andere
Architekturansatz
Lars Röwekamp
CIO New Technologies
@mobileLarson
@_openknowledge
#WISSENTEILEN

2. Branchenneutrale Softwareentwicklung und IT-Beratung
ÜBER OPEN KNOWLEDGE
#WISSENTEILEN

3. Lars Röwekamp (a.k.a. @mobileLarson)
ÜBER MICH
LR
#WISSENTEILEN
Wer bin ich - und wen ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast
• mehrfacher Vater, einfacher Ehemann

4. Es könnte alles
so einfach sein!

5. #WISSENTEILEN
CQRS

6. #WISSENTEILEN
CQRS

7. #WISSENTEILEN
CQRS
Greetings
from
Eric

8. #WISSENTEILEN
CQRS
Greetings
from
Eric

9. #WISSENTEILEN
CQRS
Greetings
from
Eric
In sich konsistentes Modell via
Aggregates, Entities, Value Objects,
Builder, Services, Repositories, ...
Validierung, Relationen, Mapping, Rules ...

10. Isses aber nich ...

11. #WISSENTEILEN
CQRS
Greetings
from
Eric
In sich konsistentes Modell via
Aggregates, Entities, Value Objects,
Builder, Services, Repositories, ...
Validierung, Relationen, Mapping, Rules ...

12. #WISSENTEILEN
CQRS
Write

13. #WISSENTEILEN
CQRS
Read

14. #WISSENTEILEN
CQRS

15. #WISSENTEILEN
CQRS
ReadWrite

16. #WISSENTEILEN
CQRS

17. #WISSENTEILEN
CQRS

18. #WISSENTEILEN
CQRS

19. #WISSENTEILEN
CQRS
Verletzung des SRP auf Architekturebene

20. #WISSENTEILEN
CQRS
Benutzerinteraktion vs. Datenbereitstellung

21. #WISSENTEILEN
CQRS
Domänen-Modell als Kompromiss für „Read“ & „Write“

22. CQRS
#WISSENTEILEN
Domänen-Modell als Kompromiss für R & W
• Business vs. Technologie?
• Entities, DTOs, VOs?
• Architektur Over-Engineering
• Optimistic Locking
• Caching

23. CQRS
#WISSENTEILEN
Domänen-Modell als Kompromiss für R & W
• Read vs. Write Performance
• Read vs. Write Skalierung
• Read vs. Write Optimierung

24. CQRS
#WISSENTEILEN
Klassische Ein-Domänen Architektur
Die Komplexität der Änderungen &
Erweiterungen steigt mit der Komplexität
des Domänenmodells

25. „A single model cannot be
appropriate for reporting,
searching, and transactional
behaviors.” Greg Young

26. „Every method should either be
a command, that performs an
action or a query that returns
data to the caller, but not both.”
Bertrand Meyer

27. „Every method should either be
a command, that performs an
action or a query that returns
data to the caller, but not both.”
Bertrand Meyer

28. Bertrand Meyer
C ommand
Q uery
R ?
S ?

29. Bertrand Meyer
C ommand
Q uery
R esponsibility
S egregation

30. #WISSENTEILEN
CQRS

31. #WISSENTEILEN
CQRS

32. #WISSENTEILEN
CQRS

33. #WISSENTEILEN
CQRS
Create
Cutomer
Cutomer
Created
Find all
Customers with ...

34. #WISSENTEILEN
CQRS
// BEFORE: CRUD based interface with no DDD usage
interface CustomerService {
Customer createCustomer(Customer cust);
void updateCustomer(Customer cust);
void deleteCustomer(String id);
Customer getCustomer(String id);
List<Customer> findCustomer(String query);
}

35. #WISSENTEILEN
CQRS
// AFTER: CQRS based interfaces with DDD usage
interface CustomerQueryService {
Customer findCustomerWith(Name uniqueName);
List<Customer> findAllCustomerMatching(SearchQuery sq);
}
interface CustomerCommandService {
Customer moveTo(Address newAddress);
Customer marry(Name newName, Partner partner);
}

36. Und was bedeutet
das für die
Architektur?

37. #WISSENTEILEN
CQRS
Read Side ...
• optimiert für Abfragen
• kurze Antwortzeiten
• unterschiedliche „Sichten“
• einfach zu skalieren
• möglichst denormalisiert
Write Side ...
• „Kommandos“ ausführen
• Validierung
• Datenkonsistenz
• ACID
• Verhalten Teil der Domäne

38. #WISSENTEILEN
CQRS

39. #WISSENTEILEN
CQRS

40. #WISSENTEILEN
CQRS

41. #WISSENTEILEN
CQRS

42. #WISSENTEILEN
CQRS

43. #WISSENTEILEN
CQRS

44. #WISSENTEILEN
CQRS

45. #WISSENTEILEN
FAZIT
„Starbucks does not use
Two-Phase Commit“
http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html

46. #WISSENTEILEN
CQRS

47. #WISSENTEILEN
CQRS

48. #WISSENTEILEN
CQRS

49. #WISSENTEILEN
CQRS

50. #WISSENTEILEN
CQRS
Write Read

51. Moment, was macht
ihr da mit meinen
„Entities“?

52. #WISSENTEILEN
CQRS & Event Sourcing
... Änderungen „sammeln“ statt State updaten!
State vs. immutable Facts ...
BTW: Immutable!

53. #WISSENTEILEN
CQRS & Event Sourcing
... Änderungen „sammeln“ statt State updaten!
State vs. immutable Facts ...
BTW: Immutable!

54. #WISSENTEILEN
CQRS & Event Sourcing
... Änderungen „sammeln“ statt State updaten!
State vs. immutable Facts ...

55. #WISSENTEILEN
CQRS & Event Sourcing
... Änderungen „sammeln“ statt State updaten!
State vs. immutable Facts ...

56. CQRS & Event Sourcing
#WISSENTEILEN
Festhalten der Änderungen via Events
• speichern der Events in korrekter Reihenfolge
• vollständige Historie implizit
• keine „Updates“ oder „Deletes“
• kein „Current State“
• „Current State“ ergibt sich durch „Replay“ der
Events für einen bestimmten Zeitpunkt!

57. CQRS & Event Sourcing
#WISSENTEILEN
Festhalten der Änderungen via Events
• „Kein“ Locking bei konkurrierenden Zugriffen
(Repräsentation durch zwei Events)
• Evolution des Models problemlos möglich
(neueinspielen der Events)
• Tests auf Command- & Eventebene
(wenn dieses Command, dann das Ergebnis)

58. WT#?

59. Wo bleibt da die
Konsistenz?

60. #WISSENTEILEN
FAZIT
„Starbucks does not use
Two-Phase Commit“
http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html

61. Ist das
nicht super
langsam?

62. CQRS & Event Sourcing
#WISSENTEILEN
Ist das nicht super langsam?
• In der Regel wenige Events pro Aggregate
• Problem bei langlebenden Entities
• Problem bei regelmäßigen Änderungen
• Snapshots als Lösung (Momento Pattern)
• ABER: Events niemals ändern/löschen!

63. #WISSENTEILEN
CQRS & Event Sourcing

64. #WISSENTEILEN
CQRS & Event Sourcing

65. #WISSENTEILEN
CQRS & Event Sourcing

66. #WISSENTEILEN
CQRS & Event Sourcing

67. Still time
for a Demo?

68. #WISSENTEILEN
CQRS & Event Sourcing
(siehe https://blog.jayway.com/2013/03/08/aggregates-event-sourcing-distilled/)

69. Muss das denn so
kompliziert sein?

70. CQRS & Event Sourcing
#WISSENTEILEN
JA! Denn, ...
• es ist extrem schnell für den Anwender
• es ist extrem einfach skalierbar
• es ist extrem einfach erweiterbar
• das Domänen-Modell bleibt konsistent
• Fehler können rekonstruiert werden
• Auditing & History gibt es quasi geschenkt

71. #WISSENTEILEN

72. #WISSENTEILEN
FAZIT

73. #WISSENTEILEN
FAZIT

74. #WISSENTEILEN
FAZIT

75. #WISSENTEILEN
FAZIT

76. FAZIT
#WISSENTEILEN
Die Benefits
• Fachlichkeit im Fokus (auch im Code!)
• Optimierung auf „Komponentenebene“
• max. Performance für High-Load Szenarien
• getrennte Evolution möglich (fachl./tech.)
• detaillierte Nachverfolgung aller Vorgänge
• Total Cost of Ownership

77. FAZIT
#WISSENTEILEN
Die Pitfals
• Komplexität gegenüber CRUD Anwendungen
• Performance bei Event-Replay
• Seiteneffekte durch Event-Replay / Snapshot
• Eventual Consistency in Query Views
• Concurrent Writes durch Commands
• Ramp-Up Zeit

78. #WISSENTEILEN
Two models
to rule them all.
FAZIT

79. #WISSENTEILEN
Focus on
Business first!
FAZIT

80. #WISSENTEILEN
Schrei nach Consistency
ist meist das Fehlen eines
fachlichen Plan B!
FAZIT

81. #WISSENTEILEN
Microservices & JEE?
Best Friends Forever!
FAZIT
„BFF“
Best Friends Forever!

82. #WISSENTEILEN

83. #WISSENTEILEN
? # !

84. LARS RÖWEKAMP
CIO NEW TECHNOLOGIES
lars.roewekamp@openknowledge.de
+49 (0) 441 4082 – 0
@mobileLarson
@_openknowledge
OFFENKUNDIGGUT
KOTAKT
#WISSENTEILEN

85. #80: © marekuliasz– shutterstock.com
#1, #45, #79: pixabay.com
Icons in this presentation designed by “Freepik”,
BILDNACHWEISE
#WISSENTEILEN