Die Themen Command Query Responsibility Segregation, kurz CQRS, und Microservices sind derzeit in aller Munde. Häufig werden die beiden Themen jedoch getrennt besprochen. So wird CQRS als neues Architekturpattern gehandelt, welches eine Abkehr vom klassischen Schichtmodell darstellt. Parallel dazu werden Microservices als modernes Architektur- und Deploymentmodell vorgestellt, welches zum einen die bestehenden Probleme der klassischen Application-Server Welt adressiert und welches sich als neue Denkweise für Service Orientierte Architekturen empfiehlt. Beide Ansätze sind für sich alleine betrachtet sehr interessant allerdings bilden sie vor allem in Kombination miteinander ein äusserst attraktives Modell für künftige IT-Landschaften. Der Vortrag wird dieses Modell vorstellen. Des Weiteren zielt der Vortrag auf eine kritische Auseinandersetzung mit diesem Architekturmodell ab.

1. CQRS basierte
Architekturen
mit
Microservices

2. Michael Plöd
@bitboss

3. Die klassische, bewährte
N-Tier Software-
Architektur

4. IncidentSOAPEndpoint
IncidentBusinessService
IncidentDAO
Incident
View
Model
Incident!
Business
Model
Client
Incident
DTO
RDBMS
Incident
ER-Model
Netzwerk
Netzwerk

5. Charakteristika

6. 1 Wir lesen und schreiben
Daten über den identischen
Weg
IncidentSOAPEndpoint
IncidentBusinessService
IncidentDAO
Incident
View
Model
Incident!
Business
Model
Client
Incident
DTO
RDBMS
Incident
ER-Model
Netzwerk
Netzwerk
WRITE
READ

7. 2 Wir verwenden für Lesen
und Schreiben das gleiche
Modell
IncidentSOAPEndpoint
IncidentBusinessService
IncidentDAO
Incident
View
Model
Incident!
Business
Model
Client
Incident
DTO
RDBMS
Incident
ER-Model
Netzwerk
Netzwerk

8. 3 Grobgranulares
Deployment
Client
IncidentSOAPEndpoint
IncidentBusinessService
IncidentDAO
RDBMS
Frontend-Server
Backend-Server
Datenbank-Server

9. ?Probleme

10. Zahlreiche Anwendungen
fahren mit der klassischen
Architektur gut

11. Es gibt dennoch Bereiche, in
denen dieses
Architekturmodell an seine
Grenzen stößt

12. 1 Datenmodell ist ein
Kompromiss
2 Skalierbarkeit
3 Hang zum Monolithen

13. CQRS

14. Command
Query
Responsibility
Separation

15. !
CQRS ist ein
Pattern, keine
Architektur

16. IncidentSOAPEndpoint
IncidentBusinessService
IncidentDAO
Incident
View
Model
Incident!
Business
Model
Client
Incident
DTO
RDBMS
Incident
ER-Model
Netzwerk
Netzwerk

17. Einfache CQRS
Architektur
IncidentQueryEndpoint
IncidentQueryService
IncidentQueryDAO
Netzwerk
RDBMS
IncidentCommandEndpoint
IncidentCommandService
IncidentCommandDAO

18. Code Beispiel

19. Klassisches Interface
public interface IncidentManagementService {!
! Incident saveIncident(Incident i);!
! void updateIncident(Incident i);!
! List<Incident> retrieveBySeverity(Severity s);!
! Incident retriveById(Long id);!
}

20. CQRS Interface
public interface IncidentManagementQueryService {!
! List<Incident> retrieveBySeverity(Severity s);!
! Incident retriveById(Long id);!
}
public interface IncidentManagementCommandService {!
! Incident saveIncident(Incident i);!
! void updateIncident(Incident i);!
}

21. 1 Optimiertes Lese- und
Schreib-Modell

22. Getrenntes Model
IncidentQueryEndpoint
IncidentQueryService
IncidentQueryDAO
Netzwerk
RDBMS
IncidentCommandEndpoint
IncidentCommandService
IncidentCommandDAO
Read
Model
Write
Model
Achtung: aktuell laufen beide
Models noch auf ein
gemeinsames Datenbank-
Modell zusammen

23. 2 CQRS ist gut für Event
Sourcing geeignet

24. Klassische Architektur
IncidentRestController
IncidentBusinessService
IncidentDAO
Incident
ID USER_ID DATUM TEXT
1 23423 11.03.2014 Maus defekt
2 67454 12.03.2014 EMail Empfang
3 93729 12.03.2014 Monitor defekt
… … … …

25. Update
IncidentRestController
IncidentBusinessService
IncidentDAO
Incident
ID USER_ID DATUM TEXT
1 23423 11.03.2014 Maus ist kaputt"
2 67454 12.03.2014 EMail Empfang
3 93729 12.03.2014 Monitor defekt
… … … …

26. Update
IncidentRestController
IncidentBusinessService
Der Datensatz wird direkt geändert.
IncidentDAO
Incident
Keine Historie
ID USER_ID DATUM TEXT
1 23423 11.03.2014 Maus ist kaputt"
2 67454 12.03.2014 EMail Empfang
3 93729 12.03.2014 Monitor defekt
… … … …

27. Event Sourcing ist ein
Architekturstil bei dem
der Zustand der Daten
einer Anwendung aus
einer Sequenz von
Events bestimmt wird

28. Event Sourcing
IncidentCreateEvent
incidentNumber: 1
userNumber: 23423!
timestamp: 11.03.2014 12:23:23
text: „Maus defekt“!
status: „offen“
IncidentUpdateEvent
incidentNumber: 1
text: „Maus ist Kaputt“
IncidentUpdateEvent
incidentNumber: 1
solution: „Neue Maus“!
status: „geschlossen“

29. Event Sourcing
Select * from Insert into
EventHandler EEvveennttss
IncidentCommandEndpoint
IncidentCommandService
IncidentCommandDAO
RDBMS
IncidentQueryEndpoint
IncidentQueryService
IncidentQueryDAO
Lese Datenhaltung
Events

30. 3 CQRS eignet sich gut für
asynchrones Processing /
messaging Patterns

31. Async CQRS
Commands können
asynchron prozessiert
Select * from Insert into
EventHandler EEvveennttss
IncidentCommandEndpoint
IncidentCommandService
IncidentCommandDAO
RDBMS
IncidentQueryEndpoint
IncidentQueryService
IncidentQueryDAO
Lese Datenhaltung
Events
werden

32. Microservices

33. Martin Fowler:
„In short, the microservice
architectural style is an approach to
developing a single application as a
suite of small services, each running in
its own process and communicating
with lightweight mechanisms, often an
HTTP resource API.“
http://martinfowler.com/articles/microservices.html

34. CQRS basierte
Anwendungen eignen sich
hervorragend für ein
Microservice-Modell

35. Command und Query
Incident
CommandMicroservice
Incident
QueryMicroservice
Split
EEvveennttss
Events
EventHandling
Microservice
IncidentQueryEndpoint
IncidentQueryService
IncidentQueryDAO
Lese Datenhaltung
IncidentCommandEndpoint
IncidentCommandService
IncidentCommandDAO
RDBMS

36. 1 Individuelle Skalierbarkeit
2 Technologie-Freiheit für
Query, Command und
Event Handling Teil
3 Vermeidung von
Monolithen

37. ? Eignung

38. Fragen?
Michael Plöd"
@bitboss"
http://slideshare.net/mploed"
michael.ploed@gmail.com