Scribd
Upload
9 views

Query

Uploaded by

Greg Young
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views

Query

Uploaded by

Greg Young
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Query

A Query is the partner in crime to a Command. Whereas Commands are used


to change information in the system, queries are used to read information from
the system.
Commands should not return data, and queries should not mutate state.
When it is said that a query should not mutate state this is referring to a
conceptual level. It is perfectly acceptable to as example log the queries that
a system receives for load analysis, access logging, or similar purposes. A
query, however, should not be mutating state associated from a business domain
perspective.
A query in general is that I would like to read some data.
GetCustomer id=1234
Customer {
id : 1234,
name : "Olive Yew",
address {
street : "123 some st.",
city : "Nowhereville",
state : "North Dakota",
postal : "37498"
},
signedUp : "1/2/2014",
.
.
.
}
There are many ways of implementing queries. They could be implemented
as messages through a bus, direct calls, etc., but most people tend to
implement them by exposing them as an HTTP URI. It is quite an easy
interface to just http://mydomain.com/customers/customerlist?page=2 or
http://mydomain.com/customers/4 to access information.
Using HTTP also allows for another quite useful feature to be used: Content-Type
negotiation.
It is quite useful to be able to return your queries in multiple formats. Perhaps
some clients want them in XML, others in JSON, others in Avro, and for some
queries a client wants the results in CSV. Supporting your queries over HTTP
makes this a relatively trivial thing to be able to do.
You can further not only use Content-Type negotiation for choosing a format
to return things in, you can also use it for dealing with versioning of the data
object over time. You can have some clients who understand version 2 of a given

1
DTO (Data Transfer Object) but not version 4, they can request to receive the
version 2 format of that DTO. Others can request the version 4 format of that
DTO.
When using versioning like this the goal is to deprecate older versions over
time as opposed to causing a “shock” by making changes that break consumers.
Obviously there are limits to this. Asking for version 3 of something when
the system is currently at version 23 is a bit extreme. There should be a well-
thought-out strategy in terms of how to deprecate things over time. There’s no
one-size-fits-all answer to this question. It depends much on the organization
including team structures, industry, total number of integration points, and level
of general incompetence.
A good strategy to look at in most organizations would be a deprecation strategy
somewhere between 30 and 180 days. If others cannot handle moving forward
within six months there are larger issues going on which likely need to be
addressed. Maintaining DTOs longer than six months can become quite arduous
over time.
Where precisely this line sits is highly organization specific, but six months is a
good high end. Over time, try to move this period of time down, three months
is a much more reasonable goal to be hitting. There is a substantial amount of
overhead which can come into play based upon this period of time being long.

You might also like