Greg Young - CQRS and Event Sourcing - Code on the Beach 2014. Design Patterns. CQRS. Domain driven design · application architecture · API design tags: CQRS stands for Command Query Responsibility Segregation.
It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information. For some situations, this separation can be valuable, but beware that for most systems CQRS adds risky complexity. The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore. As our needs become more sophisticated we steadily move away from that model.
As this occurs we begin to see multiple representations of information. This structure of multiple layers of representation can get quite complicated, but when people do this they still resolve it down to a single conceptual representation which acts as a conceptual integration point between all the presentations. There's room for considerable variation here. When to use it.
CQRS (partie 2) Dans le billet CQRS l’architecture aux deux visages (partie 1), nous vous avions présenté les bases d’une architecture CQRS.
En effet une application combine des fonctionnalités de consultation d’une part (Read) et traitement métier d’autre part (Write). CQRS propose d’aborder ces deux groupes de fonctionnalités comme deux contextes d’utilisation distincts afin d’appliquer des stratégies de design adaptées à leurs besoins spécifiques. Dans cet article, nous allons essayer d’apporter des réponses à la question laissée en suspens : comment construire une application satisfaisant aux exigences liées au contexte de restitution d’information d’une part, et au contexte de traitement de l’information d’autre part, tout en conservant un modèle explicite respectant les principes DDD évoqués dans l’article Domain Driven Design, des armes pour affronter la complexité (« Domain-driven design is not a technology or a methodology. De très bons articles détaillent ce que sont les domain events. Bilan. CQRS (partie 1) Dans un article précédent, nous avons vu comment l’approche DDD, via la définition et l’utilisation d’un Ubiquitous Language et d’un véritable modèle du domaine, peut faciliter la communication entre acteurs projet, aider à l’écriture d’un code plus expressif (et donc plus maintenable), et capable d’adresser la complexité – et les changements – du métier.
Aujourd’hui, nous allons essayer de répondre à certaines questions laissées en suspens par notre première approche de DDD. Comment éviter de multiplier les couches de mapping, sans valeur ajoutée, à différents niveaux de notre architecture ? Comment aller plus loin dans le respect des principes objet tels que l’encapsulation ? Comment faciliter la réalisation d’IHM orientées tâches et activités, présentant des informations vraiment pertinentes pour l’utilisateur ? L’utilisation d’un modèle objet riche est-elle synonyme de dégradation des performances ? « Two players, two sides » : John Locke (LOST) nous avait mis sur la voie… Mais… Event Sourcing & noSQL.
0909.1788. Remediation Patterns. Enterprise Integration Patterns. SOA Patterns.