SlideShare ist ein Scribd-Unternehmen logo
CQRS basierte 
Architekturen 
mit 
Microservices
Michael Plöd 
@bitboss
Die klassische, bewährte 
N-Tier Software- 
Architektur
IncidentSOAPEndpoint 
IncidentBusinessService 
IncidentDAO 
Incident 
View 
Model 
Incident! 
Business 
Model 
Client 
Incident 
DTO 
RDBMS 
Incident 
ER-Model 
Netzwerk 
Netzwerk
Charakteristika
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
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
3 Grobgranulares 
Deployment 
Client 
IncidentSOAPEndpoint 
IncidentBusinessService 
IncidentDAO 
RDBMS 
Frontend-Server 
Backend-Server 
Datenbank-Server
?Probleme
Zahlreiche Anwendungen 
fahren mit der klassischen 
Architektur gut
Es gibt dennoch Bereiche, in 
denen dieses 
Architekturmodell an seine 
Grenzen stößt
1 Datenmodell ist ein 
Kompromiss 
2 Skalierbarkeit 
3 Hang zum Monolithen
CQRS
Command 
Query 
Responsibility 
Separation
! 
CQRS ist ein 
Pattern, keine 
Architektur
IncidentSOAPEndpoint 
IncidentBusinessService 
IncidentDAO 
Incident 
View 
Model 
Incident! 
Business 
Model 
Client 
Incident 
DTO 
RDBMS 
Incident 
ER-Model 
Netzwerk 
Netzwerk
Einfache CQRS 
Architektur 
IncidentQueryEndpoint 
IncidentQueryService 
IncidentQueryDAO 
Netzwerk 
RDBMS 
IncidentCommandEndpoint 
IncidentCommandService 
IncidentCommandDAO
Code Beispiel
Klassisches Interface 
public interface IncidentManagementService {! 
! Incident saveIncident(Incident i);! 
! void updateIncident(Incident i);! 
! List<Incident> retrieveBySeverity(Severity s);! 
! Incident retriveById(Long id);! 
}
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);! 
}
1 Optimiertes Lese- und 
Schreib-Modell
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
2 CQRS ist gut für Event 
Sourcing geeignet
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 
… … … …
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 
… … … …
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 
… … … …
Event Sourcing ist ein 
Architekturstil bei dem 
der Zustand der Daten 
einer Anwendung aus 
einer Sequenz von 
Events bestimmt wird
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“
Event Sourcing 
Select * from Insert into 
EventHandler EEvveennttss 
IncidentCommandEndpoint 
IncidentCommandService 
IncidentCommandDAO 
RDBMS 
IncidentQueryEndpoint 
IncidentQueryService 
IncidentQueryDAO 
Lese Datenhaltung 
Events
3 CQRS eignet sich gut für 
asynchrones Processing / 
messaging Patterns
Async CQRS 
Commands können 
asynchron prozessiert 
Select * from Insert into 
EventHandler EEvveennttss 
IncidentCommandEndpoint 
IncidentCommandService 
IncidentCommandDAO 
RDBMS 
IncidentQueryEndpoint 
IncidentQueryService 
IncidentQueryDAO 
Lese Datenhaltung 
Events 
werden
Microservices
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
CQRS basierte 
Anwendungen eignen sich 
hervorragend für ein 
Microservice-Modell
Command und Query 
Incident 
CommandMicroservice 
Incident 
QueryMicroservice 
Split 
EEvveennttss 
Events 
EventHandling 
Microservice 
IncidentQueryEndpoint 
IncidentQueryService 
IncidentQueryDAO 
Lese Datenhaltung 
IncidentCommandEndpoint 
IncidentCommandService 
IncidentCommandDAO 
RDBMS
1 Individuelle Skalierbarkeit 
2 Technologie-Freiheit für 
Query, Command und 
Event Handling Teil 
3 Vermeidung von 
Monolithen
? Eignung
Fragen? 
Michael Plöd" 
@bitboss" 
http://slideshare.net/mploed" 
michael.ploed@gmail.com

Weitere ähnliche Inhalte

Andere mochten auch

Der perfekte Microservice
Der perfekte MicroserviceDer perfekte Microservice
Der perfekte Microservice
OPEN KNOWLEDGE GmbH
 
Reactive Development: Commands, Actors and Events. Oh My!!
Reactive Development: Commands, Actors and Events.  Oh My!!Reactive Development: Commands, Actors and Events.  Oh My!!
Reactive Development: Commands, Actors and Events. Oh My!!
David Hoerster
 
Continuous Delivery @ FriendScout24 | Webinale 2012
Continuous Delivery @ FriendScout24 | Webinale 2012Continuous Delivery @ FriendScout24 | Webinale 2012
Continuous Delivery @ FriendScout24 | Webinale 2012
Michael Maretzke
 
Creating scalable message driven solutions akkadotnet
Creating scalable message driven solutions akkadotnetCreating scalable message driven solutions akkadotnet
Creating scalable message driven solutions akkadotnet
David Hoerster
 
CQRS Evolved - CQRS + Akka.NET
CQRS Evolved - CQRS + Akka.NETCQRS Evolved - CQRS + Akka.NET
CQRS Evolved - CQRS + Akka.NET
David Hoerster
 
Akka in Practice: Designing Actor-based Applications
Akka in Practice: Designing Actor-based ApplicationsAkka in Practice: Designing Actor-based Applications
Akka in Practice: Designing Actor-based Applications
NLJUG
 
CQRS and Event Sourcing, An Alternative Architecture for DDD
CQRS and Event Sourcing, An Alternative Architecture for DDDCQRS and Event Sourcing, An Alternative Architecture for DDD
CQRS and Event Sourcing, An Alternative Architecture for DDD
Dennis Doomen
 
Akka persistence == event sourcing in 30 minutes
Akka persistence == event sourcing in 30 minutesAkka persistence == event sourcing in 30 minutes
Akka persistence == event sourcing in 30 minutes
Konrad Malawski
 
Everything-as-code. Polyglotte Software-Entwicklung in der Praxis.
Everything-as-code. Polyglotte Software-Entwicklung in der Praxis.Everything-as-code. Polyglotte Software-Entwicklung in der Praxis.
Everything-as-code. Polyglotte Software-Entwicklung in der Praxis.
QAware GmbH
 
Event-sourced architectures with Akka
Event-sourced architectures with AkkaEvent-sourced architectures with Akka
Event-sourced architectures with Akka
Sander Mak (@Sander_Mak)
 
Bessere Präsentationen
Bessere PräsentationenBessere Präsentationen
Bessere Präsentationen
Michael Plöd
 
Warum empfehle ich meinen Kunden das Spring Framework?
Warum empfehle ich meinen Kunden das Spring Framework? Warum empfehle ich meinen Kunden das Spring Framework?
Warum empfehle ich meinen Kunden das Spring Framework?
Michael Plöd
 

Andere mochten auch (12)

Der perfekte Microservice
Der perfekte MicroserviceDer perfekte Microservice
Der perfekte Microservice
 
Reactive Development: Commands, Actors and Events. Oh My!!
Reactive Development: Commands, Actors and Events.  Oh My!!Reactive Development: Commands, Actors and Events.  Oh My!!
Reactive Development: Commands, Actors and Events. Oh My!!
 
Continuous Delivery @ FriendScout24 | Webinale 2012
Continuous Delivery @ FriendScout24 | Webinale 2012Continuous Delivery @ FriendScout24 | Webinale 2012
Continuous Delivery @ FriendScout24 | Webinale 2012
 
Creating scalable message driven solutions akkadotnet
Creating scalable message driven solutions akkadotnetCreating scalable message driven solutions akkadotnet
Creating scalable message driven solutions akkadotnet
 
CQRS Evolved - CQRS + Akka.NET
CQRS Evolved - CQRS + Akka.NETCQRS Evolved - CQRS + Akka.NET
CQRS Evolved - CQRS + Akka.NET
 
Akka in Practice: Designing Actor-based Applications
Akka in Practice: Designing Actor-based ApplicationsAkka in Practice: Designing Actor-based Applications
Akka in Practice: Designing Actor-based Applications
 
CQRS and Event Sourcing, An Alternative Architecture for DDD
CQRS and Event Sourcing, An Alternative Architecture for DDDCQRS and Event Sourcing, An Alternative Architecture for DDD
CQRS and Event Sourcing, An Alternative Architecture for DDD
 
Akka persistence == event sourcing in 30 minutes
Akka persistence == event sourcing in 30 minutesAkka persistence == event sourcing in 30 minutes
Akka persistence == event sourcing in 30 minutes
 
Everything-as-code. Polyglotte Software-Entwicklung in der Praxis.
Everything-as-code. Polyglotte Software-Entwicklung in der Praxis.Everything-as-code. Polyglotte Software-Entwicklung in der Praxis.
Everything-as-code. Polyglotte Software-Entwicklung in der Praxis.
 
Event-sourced architectures with Akka
Event-sourced architectures with AkkaEvent-sourced architectures with Akka
Event-sourced architectures with Akka
 
Bessere Präsentationen
Bessere PräsentationenBessere Präsentationen
Bessere Präsentationen
 
Warum empfehle ich meinen Kunden das Spring Framework?
Warum empfehle ich meinen Kunden das Spring Framework? Warum empfehle ich meinen Kunden das Spring Framework?
Warum empfehle ich meinen Kunden das Spring Framework?
 

Ähnlich wie CQRS basierte Architekturen mit Microservices

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
QAware GmbH
 
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - WinterbergEvent Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
OPITZ CONSULTING Deutschland
 
Cybersecurity
CybersecurityCybersecurity
Cybersecurity
remyguillaume
 
Migration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud PlattformMigration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud Plattform
QAware GmbH
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
OPEN KNOWLEDGE GmbH
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
QAware GmbH
 
A Hitchhiker's Guide to the Cloud Native Stack
A Hitchhiker's Guide to the Cloud Native StackA Hitchhiker's Guide to the Cloud Native Stack
A Hitchhiker's Guide to the Cloud Native Stack
QAware GmbH
 
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConfA Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
Mario-Leander Reimer
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
QAware GmbH
 
batbern43 Command & Events Divide and conquer in Microservice Architekturen
batbern43 Command & Events Divide and conquer in Microservice Architekturenbatbern43 Command & Events Divide and conquer in Microservice Architekturen
batbern43 Command & Events Divide and conquer in Microservice Architekturen
BATbern
 
Cloud Computing
Cloud ComputingCloud Computing
Cloud Computing
Thomas Krampe
 
Vert.x kubernetes
Vert.x kubernetesVert.x kubernetes
Vert.x kubernetes
codepitbull
 
Holistische Sicherheit für Microservice Architekturen
Holistische Sicherheit für Microservice ArchitekturenHolistische Sicherheit für Microservice Architekturen
Holistische Sicherheit für Microservice Architekturen
QAware GmbH
 
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudFrom Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
OPEN KNOWLEDGE GmbH
 
Cloud-Native ohne Vendor Lock-in mit Kubernetes
Cloud-Native ohne Vendor Lock-in mit KubernetesCloud-Native ohne Vendor Lock-in mit Kubernetes
Cloud-Native ohne Vendor Lock-in mit Kubernetes
ConSol Consulting & Solutions Software GmbH
 
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareAndreas Schreiber
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
OPEN KNOWLEDGE GmbH
 
Holistische Sicherheit für Microservice-basierte Systeme
Holistische Sicherheit für Microservice-basierte SystemeHolistische Sicherheit für Microservice-basierte Systeme
Holistische Sicherheit für Microservice-basierte Systeme
QAware GmbH
 
Cloud-native Apps 2.0
Cloud-native Apps 2.0Cloud-native Apps 2.0
Cloud-native Apps 2.0
QAware GmbH
 
Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?
QAware GmbH
 

Ähnlich wie CQRS basierte Architekturen mit Microservices (20)

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - WinterbergEvent Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
 
Cybersecurity
CybersecurityCybersecurity
Cybersecurity
 
Migration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud PlattformMigration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud Plattform
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
A Hitchhiker's Guide to the Cloud Native Stack
A Hitchhiker's Guide to the Cloud Native StackA Hitchhiker's Guide to the Cloud Native Stack
A Hitchhiker's Guide to the Cloud Native Stack
 
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConfA Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
batbern43 Command & Events Divide and conquer in Microservice Architekturen
batbern43 Command & Events Divide and conquer in Microservice Architekturenbatbern43 Command & Events Divide and conquer in Microservice Architekturen
batbern43 Command & Events Divide and conquer in Microservice Architekturen
 
Cloud Computing
Cloud ComputingCloud Computing
Cloud Computing
 
Vert.x kubernetes
Vert.x kubernetesVert.x kubernetes
Vert.x kubernetes
 
Holistische Sicherheit für Microservice Architekturen
Holistische Sicherheit für Microservice ArchitekturenHolistische Sicherheit für Microservice Architekturen
Holistische Sicherheit für Microservice Architekturen
 
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudFrom Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
 
Cloud-Native ohne Vendor Lock-in mit Kubernetes
Cloud-Native ohne Vendor Lock-in mit KubernetesCloud-Native ohne Vendor Lock-in mit Kubernetes
Cloud-Native ohne Vendor Lock-in mit Kubernetes
 
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
 
Holistische Sicherheit für Microservice-basierte Systeme
Holistische Sicherheit für Microservice-basierte SystemeHolistische Sicherheit für Microservice-basierte Systeme
Holistische Sicherheit für Microservice-basierte Systeme
 
Cloud-native Apps 2.0
Cloud-native Apps 2.0Cloud-native Apps 2.0
Cloud-native Apps 2.0
 
Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?Cloud Native & Java EE: Freund oder Feind?
Cloud Native & Java EE: Freund oder Feind?
 

Mehr von Michael Plöd

Building Microservices with Event Sourcing and CQRS
Building Microservices with Event Sourcing and CQRSBuilding Microservices with Event Sourcing and CQRS
Building Microservices with Event Sourcing and CQRS
Michael Plöd
 
Migrating from Grails 2 to Grails 3
Migrating from Grails 2 to Grails 3Migrating from Grails 2 to Grails 3
Migrating from Grails 2 to Grails 3
Michael Plöd
 
Event Sourcing: Introduction & Challenges
Event Sourcing: Introduction & ChallengesEvent Sourcing: Introduction & Challenges
Event Sourcing: Introduction & Challenges
Michael Plöd
 
Caching in Hibernate
Caching in HibernateCaching in Hibernate
Caching in Hibernate
Michael Plöd
 
Spring One 2 GX 2014 - CACHING WITH SPRING: ADVANCED TOPICS AND BEST PRACTICES
Spring One 2 GX 2014 - CACHING WITH SPRING: ADVANCED TOPICS AND BEST PRACTICESSpring One 2 GX 2014 - CACHING WITH SPRING: ADVANCED TOPICS AND BEST PRACTICES
Spring One 2 GX 2014 - CACHING WITH SPRING: ADVANCED TOPICS AND BEST PRACTICES
Michael Plöd
 
Caching - Hintergründe, Patterns und Best Practices
Caching - Hintergründe, Patterns und Best PracticesCaching - Hintergründe, Patterns und Best Practices
Caching - Hintergründe, Patterns und Best Practices
Michael Plöd
 
Integrating Wicket with Java EE 6
Integrating Wicket with Java EE 6Integrating Wicket with Java EE 6
Integrating Wicket with Java EE 6
Michael Plöd
 

Mehr von Michael Plöd (8)

Building Microservices with Event Sourcing and CQRS
Building Microservices with Event Sourcing and CQRSBuilding Microservices with Event Sourcing and CQRS
Building Microservices with Event Sourcing and CQRS
 
Migrating from Grails 2 to Grails 3
Migrating from Grails 2 to Grails 3Migrating from Grails 2 to Grails 3
Migrating from Grails 2 to Grails 3
 
Event Sourcing: Introduction & Challenges
Event Sourcing: Introduction & ChallengesEvent Sourcing: Introduction & Challenges
Event Sourcing: Introduction & Challenges
 
Caching in Hibernate
Caching in HibernateCaching in Hibernate
Caching in Hibernate
 
Spring One 2 GX 2014 - CACHING WITH SPRING: ADVANCED TOPICS AND BEST PRACTICES
Spring One 2 GX 2014 - CACHING WITH SPRING: ADVANCED TOPICS AND BEST PRACTICESSpring One 2 GX 2014 - CACHING WITH SPRING: ADVANCED TOPICS AND BEST PRACTICES
Spring One 2 GX 2014 - CACHING WITH SPRING: ADVANCED TOPICS AND BEST PRACTICES
 
Caching - Hintergründe, Patterns und Best Practices
Caching - Hintergründe, Patterns und Best PracticesCaching - Hintergründe, Patterns und Best Practices
Caching - Hintergründe, Patterns und Best Practices
 
Hibernate Tuning
Hibernate TuningHibernate Tuning
Hibernate Tuning
 
Integrating Wicket with Java EE 6
Integrating Wicket with Java EE 6Integrating Wicket with Java EE 6
Integrating Wicket with Java EE 6
 

CQRS basierte Architekturen mit Microservices

  • 1. CQRS basierte Architekturen mit Microservices
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 38. Fragen? Michael Plöd" @bitboss" http://slideshare.net/mploed" michael.ploed@gmail.com