Zum Inhalt springen

„Command-Query-Responsibility-Segregation“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
→Quellen: Navigationsleiste
Vor/Nachteile gegenüber was. Falsche Information (EventSourcing, SOA, CloudComputing) rausgezogen. Unbelegtes markiert
Zeile 7: Zeile 7:
* ein Objektmodell für schreibende Zugriffe
* ein Objektmodell für schreibende Zugriffe


Im Gegensatz zu einer [[CRUD]]-Sicht für die Zugriffe auf eine Datenbank – wo also ein gemeinsames Objekt für Queries genauso wie für Lesen, Schreiben und Löschen verantwortlich ist – gibt es bei CQRS zwei Objekte: Befehle zum Schreiben (Ändern und Löschen), sowie Abfragen zum Lesen.
Im Gegensatz zu einer [[CRUD]]-Sicht für die Zugriffe auf eine Datenbank – wo also ein gemeinsames Objekt für Queries genauso wie für Lesen, Schreiben und Löschen verantwortlich ist – gibt es bei CQRS zwei Objekte: Befehle zum Schreiben (Ändern und Löschen), sowie Abfragen zum Lesen. CQRS wird oft im Zusammenhang mit [[Event Sourcing]], [[Serviceorientierte Architektur|Serviceorientierten Architekturen]], etwa im [[Cloud Computing]] erwähnt, diese Architekturen können aber genausogut auch mit [[CRUD]] kombiniert werden.


== Vorteile ==
== Vorteile gegenüber CRUD ==
* Unterschiedliche [[Skalierbarkeit]], schreibende Zugriffe können auf anderen Rechnern laufen als lesende und jeweils unterschiedlich skalieren.
* Unterschiedliche [[Skalierbarkeit]], schreibende Zugriffe können auf anderen Rechnern laufen als lesende und jeweils unterschiedlich skalieren.
* Eignet sich zum Einsatz in [[Serviceorientierte Architektur|Serviceorientierten Architekturen]], etwa im [[Cloud Computing]]
* Verbesserte Sicherheit durch getrennte Rollen der Schreib- und Leseoperationen
* Verbesserte Sicherheit durch getrennte Rollen der Schreib- und Leseoperationen
* Simultaner Einsatz verschiedener Versionen derselben Software möglich
* Simultaner Einsatz verschiedener Versionen derselben Software möglich<!-- Erklärung oder Ref dazu fehlt -->
** Beibehaltung von [[Kompatibilität (Technik)#Abwärtskompatibilität|Rückwärtskompatibilität]] möglich
** Beibehaltung von [[Kompatibilität (Technik)#Abwärtskompatibilität|Rückwärtskompatibilität]] möglich
** [[Migration (Informationstechnik)|Migration]] auf neue Version im Live-Betrieb ohne [[Downtime]] möglich
** [[Migration (Informationstechnik)|Migration]] auf neue Version im Live-Betrieb ohne [[Downtime]] möglich
* Anpassbarkeit an veränderte Geschäfts-Anforderungen
* Anpassbarkeit an veränderte Geschäfts-Anforderungen<!-- Erklärung oder Ref dazu fehlt -->
* Entwicklung der einzelnen Bestandteile durch unterschiedliche Teams
* Entwicklung der einzelnen Bestandteile durch unterschiedliche Teams
* Kann mit [[Event Sourcing]] kombiniert werden


== Nachteile ==
== Nachteile gegenüber CRUD ==
* Hoher Aufwand in der Softwareentwicklung. Eignet sich eher für Projekte mit vielen gleichzeitigen Benutzern.
* Hoher Aufwand in der Softwareentwicklung. Eignet sich eher für Projekte mit vielen gleichzeitigen Benutzern.
* Benötigt passende Infrastruktur.
* Benötigt passende Infrastruktur.

Version vom 8. April 2025, 10:32 Uhr

Funktionsprinzip von CQRS mit Event Sourcing

Die Command Query Responsibility Segregation (CQRS, [kə'mæ:nd 'kwɪ(ə)ri: ri,spɑnsə'bɪləti ,sɛgrɪ'geiʃ(ə)n] bzw. [si: kju: ɑ:r ɛs],[1] englisch für etwa „Kommando-Abfrage-Zuständigkeitstrennung“) ist ein Entwurfsmuster für Datenbank-Abfragen, welches durch Greg Young definiert wurde.[2]

Das CQRS-Pattern propagiert eine Aufteilung des Objektmodells in zwei Objektmodelle hinsichtlich der Zugriffe auf die Datenbank:[3]

  • ein Objektmodell für lesende Zugriffe
  • ein Objektmodell für schreibende Zugriffe

Im Gegensatz zu einer CRUD-Sicht für die Zugriffe auf eine Datenbank – wo also ein gemeinsames Objekt für Queries genauso wie für Lesen, Schreiben und Löschen verantwortlich ist – gibt es bei CQRS zwei Objekte: Befehle zum Schreiben (Ändern und Löschen), sowie Abfragen zum Lesen. CQRS wird oft im Zusammenhang mit Event Sourcing, Serviceorientierten Architekturen, etwa im Cloud Computing erwähnt, diese Architekturen können aber genausogut auch mit CRUD kombiniert werden.

Vorteile gegenüber CRUD

  • Unterschiedliche Skalierbarkeit, schreibende Zugriffe können auf anderen Rechnern laufen als lesende und jeweils unterschiedlich skalieren.
  • Verbesserte Sicherheit durch getrennte Rollen der Schreib- und Leseoperationen
  • Simultaner Einsatz verschiedener Versionen derselben Software möglich
  • Anpassbarkeit an veränderte Geschäfts-Anforderungen
  • Entwicklung der einzelnen Bestandteile durch unterschiedliche Teams

Nachteile gegenüber CRUD

  • Hoher Aufwand in der Softwareentwicklung. Eignet sich eher für Projekte mit vielen gleichzeitigen Benutzern.
  • Benötigt passende Infrastruktur.
  • Transaktionen sind schwer umzusetzen.
  • Querys können durchgeführt werden, bevor Commands durchgeführt wurden. Es werden daher Versionierung und ein In-Memory-Cache benötigt, um sicherzustellen, dass der Client Daten in der richtigen Version erhält.

Frameworks

Die folgenden Frameworks unterstützen bei der Umsetzung dieses Patterns:

.NET
EventFlow[4]
JavaScript
wolkenkit[5]
PHP
prooph[6]

Literatur

  • Chris Richardson: Microservices Patterns. Manning, Shelter Island NY 2019, ISBN 978-1-61729-454-9, S. 228–252 (amerikanisches Englisch).

Quellen

  1. ↑ Martin Fowler: CQRS. 14. Juli 2011, abgerufen am 18. Mai 2014 (englisch).
  2. ↑ Greg Young: CQRS Documents by Greg Young. (PDF) In: WordPress. November 2010, abgerufen am 13. Juli 2014 (englisch).
  3. ↑ Archivierte Kopie (Memento des Originals vom 28. August 2020 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/codebetter.com
  4. ↑ EventFlow. In: GitHub. Abgerufen am 30. November 2021 (englisch, CQRS- und EventSourcing-Framework für .NET Core).
  5. ↑ wolkenkit. Abgerufen am 27. Juni 2017 (englisch, CQRS-, DDD- und Event-Sourcing-Framework für JavaScript).
  6. ↑ prooph. Abgerufen am 1. Februar 2018 (englisch, CQRS und Event Sourcing Infrastruktur für PHP).
Entwurfsmuster
Erzeugungsmuster

Abstrakte Fabrik | Erbauer | Fabrikmethode | Prototyp | Singleton | Multiton | Objektpool

Strukturmuster

Adapter | Brücke | Decorator | Fassade | Fliegengewicht | Kompositum | Stellvertreter

Verhaltensmuster

Beobachter | Besucher | Interpreter | Iterator | Kommando | Memento | Schablonenmethode | Strategie | Vermittler | Zustand | Zuständigkeitskette | Interceptor | Nullobjekt | Protokollstapel

Muster für objekt-
relationale Abbildung

Datentransferobjekt | Table Data Gateway | Row Data Gateway | Active Record | Unit of Work | Identity Map | Lazy Loading | Identity Field | Dependent Mapping | Embedded Value | Serialized LOB | Inheritance Mapper | Metadata Mapping | Query Object | Command-Query-Responsibility-Segregation

Nachrichten-
übermittlungsmuster
Integrationsarten

File Transfer | Shared Database | Remote Procedure Invocation | Messaging

Nachrichtenaufbau

Message | Command Message | Document Message | Event Message | Request-Reply | Return Address | Correlation Identifier | Message Sequence | Message Expiration | Format Indicator

Endpunkte

Message Endpoint | Messaging Gateway | Messaging Mapper | Transactional Client | Polling Consumer | Event-driven Consumer | Competing Consumers | Message Dispatcher | Selective Consumer | Durable Subscriber | Idempotent Receiver | Service Activator

Kanäle

Message Channel | Point-to-Point Channel | Publisher-Subscriber Channel | Datatype Channel | Invalid Message Channel | Dead Letter Channel | Guaranteed Delivery | Channel Adapter | Messaging Bridge | Message Bus

Nachrichtenvermittlung

Pipes-and-Filters | Message Router | Content-based Router | Message Filter | Dynamic Router | Recipient List | Splitter | Aggregator | Resequencer | Composed Message Processor | Scatter-Gather | Routing Slip | Process Manager | Message Broker

Nachrichtenumwandlung

Message Translator | Envelope Wrapper | Content Enricher | Content Filter | Claim Check | Normalizer | Canonical Data Model

Systemmanagement

Control Bus | Detour | Wire Tap | Message History | Message Store | Smart Proxy | Test Message | Channel Purger

andere

Application Controller | Business Delegate | Data Access Object | Dependency Injection | Extension Interface | Fluent Interface | Inversion of Control (IoC) | Lock | Model View Controller (MVC) | Model View Presenter (MVP) | Model View Update (MVU) | Model View ViewModel (MVVM) | Page Controller | Registry | Remote Facade | Repository | Service Locator | Session State | Table Module | Template View | Threadpool | Transaction Script | Transform View | Two-Step View | Value Object

Siehe auch:  Analysemuster | Architekturmuster | Integrationsmuster | SOA-Muster
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Command-Query-Responsibility-Segregation&oldid=254960418“