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

Event Sourcing Capture all changes to an application state as a sequence of events. We can query an application's state to find out the current state of the world, and this answers many questions. However there are times when we don't just want to see where we are, we also want to know how we got there. Event Sourcing ensures that all changes to application state are stored as a sequence of events. How it Works The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself. Let's consider a simple example to do with shipping notifications. Figure 1: A simple interface for tracking shipping movements. In this case when the service is called, it finds the relevant ship and updates its location. Introducing Event Sourcing adds a step to this process. Figure 2: Using an event to capture the change.

Do we need WADL? Everybody's atwitter about WADL, a description file for REST services, and since it's supposed to be RESTful I regularly get questioned about it. For this post I'm going to experiment and adopt Stephen O'Grady's Q&A style. My thanks to Patrick Mueller and Dave Johnson for volunteering to be guinea pigs for my arguments, and thanks to #redmonk for the use of their channel where we initially held the discussion. Q: Does REST need a description document? A: No. Q: You're new to this Q&A format, aren't you? A: There are, as always, two problems. The technical problems I will get back to later. The urge to code generate is particularly strong around XML Schema. The second cultural hurdle is the implicit assumption that all useful data will be in the form of XML, which ignores the vast amount of non-XML content on the web today, which, outside of RSS and Atom, is all of it (HTML, CSS, JavaScript, podcasts, videos, JSON, etc.). A: Sure. Here is the very first example in the WADL specification:

CQRS Journey July 2012 The project is focused on building highly scalable, highly available and maintainable applications with the Command & Query Responsibility Segregation and the Event Sourcing patterns. The project was positioned as a learning journey. This guidance is designed to help you get started with the CQRS pattern and event sourcing. It is not intended to be the definitive guide to the CQRS pattern and event sourcing. Instead, it's a journal that describes the experiences of a development team with no prior CQRS proficiency in building, deploying (to Windows Azure), and maintaining a sample real-world complex enterprise system as a reference implementation (RI) to showcase various CQRS and ES concepts & techniques. The CQRS pattern and event sourcing are not mere simplistic solutions to the problems associated with large-scale, distributed systems. This guide was produced by the following individuals:

PUT or POST: The REST of the Story « Open Sourcery Web service designers have tried for some time now to correlate CRUD (Create, Retrieve, Update and Delete) semantics with the Representational State Transfer (REST) verbs defined by the HTTP specification–GET, PUT, POST, DELETE, HEAD, etc. So often, developers will try to correlate these two concepts–CRUD and REST–using a one-to-one mapping of verbs from the two spaces, like this: Create = PUTRetrieve = GETUpdate = POSTDelete = DELETE “How to Create a REST Protocol” is an example of a very well-written article about REST, but which makes this faulty assumption. In the article, “I don’t get PUT versus POST” the author clearly understands the semantic differences between PUT and POST, but fails to understand the benefits (derived from the HTTP protocol) of the proper REST semantics. But such a trivial mapping is inaccurate at best. The crux of the issue comes down to a concept known as idempotency. After that discussion, a more realistic mapping would seem to be: Analysis References Like this:

mspnp/cqrs-journey-code Is REST the future for SOA? It seems like everywhere we turn we keep hearing that SOA’s future is REST. There are a lot of publications comparing REST to SOAP and WS*[1], but such comparison seems to be too simplistic. There are two main approaches that have emerged lately – true REST and REST as a technology approach for services (aka REST Web Services[2]). In this article I will try to discuss whether either of these approaches can improve SOA implementations. True REST for SOA A true REST is effectively an implementation of Resource-Oriented architecture and not a pure technology decision. In order to assess the problem correctly, let’s first recall that the SOA architectural style [2] is based on a functional decomposition of enterprise business architecture and introduces two high-level abstractions: enterprise business services and business processes. REST, on another hand, is a set of architectural guidelines [3] expressed as Resource-Oriented Architecture (ROA). Services vs. What is a service? Simplicity 1.