So I was bad last week and didn't get much written shame on me... hopefully I can get back on track. In DDDD 10 we looked at Command Query Seperation, now we are going to take that idea a little bit further as we really need to break it down a bit more than commands and queries.
Let's say that I have a domain with a Customer Aggregate Root. When I want to update this Customer I need to issue a query to get its current state so I can validate whether my current changes would make the object en up in an invalid state. Generally for these types of reads one would want consistent data. Why bother with all of my nice validation if it can be bypassed by inconsistency? One of the key concepts in domain driven design is that I know that certain things about my objects are true.
In that same domain I may also be able to search for customers with a first name of "Greg". In this type of situation it is no longer a technical requirement (may still be a business requirement) that my search is completely consistent (for future reference I call any read such as this a "Report" even though they may not meet your personal criteria of a report).
If my search does not need to be completely consistent I can do many very neat things with my data such as having it come from a different model than my transactional model (i.e. query a reporting database). I can also do other things like cache the data with expirations. These types of operations can allow me to become much more scalable and they are a key concept we will be later exploiting in moving towards distributing our systems.
Because of how important our gains are; let's make some rules.
Aggregate roots provide the boundary for where data is always consistent. Anytime you deal with data that belongs to an aggregate from outside of an aggregate you should make your new default to assume it to be eventually consistent.
Bounded Contexts are always considered to be eventually consistent. If you have Bounded Contexts where this is not true there is probably something wrong with your model.
When I say you should make it your new default; I mean that:
Unless it is explicitly stated otherwise and a business reason is provided with the story; it will be eventually consistent.
One problem that you will run into with this transition is managing expectations. Domain Experts like most non-technical (and most technical for that matter) people have been trained to think that everything should be instantaneous with computers ("You mean when I click save and it says it saved it takes 45 seconds to show up in the search?"). They have sucked from the evil tit of the RDBMS and its global consistency for far too long. The next post will be about getting over this hurdle.