QCon San Francisco 2008 – Unleash Your Domain

22 Nov, 2008

The talk “Unshackle Your Domain” given by Greg Young was the highlight of QCon for me. An architectural approach that is relatively easy to understand, incredibly scalable, and supports a rich domain model.
At his presentation, Greg quickly pointed out some of the problems with traditional enterprise application architecture, such as JEE. This architecture usually consists of an “object-oriented” domain model encapsulated inside a procedural service layer, persisted in a relational database, flattened out on a data entry screen by the UI layer, and crunched daily into management reports by some reporting tool. With so many masters, it’s no wonder that the domain model becomes anemic and the application is hard to scale.
Greg needed something better. Something that is able to sustain 10,000 transactions per second, supports bullet-proof auditing, and has a rich domain model to implement complicated financial business logic.
His key insight is that the application should explicitly model state transition commands as classes and strictly split these commands from queries on the application interface level. So any kind of client UI or report will use the query interface of the application to get its needed data using a thin DTO layer while updates uses the command interface. These command objects also support the audit requirements and drive the domain model.
Now the domain model only supports a single concern: validating and executing commands. No longer does the domain model need to support querying, so your objects no longer need lots of getters and setters: Tell, don’t ask! In addition to this, the domain model can now be stored using a data store optimized for updates, such as Hypertable or CouchDB.
For the query interface a read-optimized database can be used, updated by events from the domain model. You can easily denormalize this database without reducing the efficiency of writes on your domain model. Furthermore, it is now possible to easily replicate this read-only store for extremely high scalability.
In the next few weeks I’ll investigate the practical implications of this approach, the needed infrastructure to get this working, and the possible applications that could benefit.

Newest Most Voted
Inline Feedbacks
View all comments
Lars Vonk
13 years ago

Hi Erik,
Does this mean you have two different databases that store the same data but in different formats? One for the query interface and one for the command interface?

Serge Beaumont
13 years ago

I’ve seen these ideas come and go every now and then. This model, though useful, is essentially a reification of the elements of objects into objects themselves, and in this case combined with Meyer’s Command-Query Separation Principle. I’ve implemented something similar once or twice, and although useful in some cases, it does make your domain model more fragmented and therefore more complex. Use with care… 🙂


[…] your Domain, a DDD session that talked about some very interesting domain modeling techniques. See Erik’s blog for more info on that session. – AtomServer – The Power of Publishing for Data Distribution. These […]

Sérgio Silva
Sérgio Silva
13 years ago

I’m interested in this issue. Is the presentation available or some related article about this solution?
I’ve checked the QCon site but I couldn’t find anything.
Thanks a lot!

Greg Young
Greg Young
13 years ago

Thanks for your kind words on the presentation. Sorry about the slides being light on details, it is a new presentation style I have been working on (valueless slides). The presentation was recorded and my guess is that it will be put up shortly after QCon London as I am doing the same talk there.
Serge: I believe you are confusing this a bit. Although the principles share a name with Meyer’s cqs they are architectural as opposed to code level. It is about separating the “read” operations (except those needed for performing “updates” out of your domain as they tend to have very different requirement (especially in terms of scaling). I would be happy to discuss this in more detail with you via email if you like as it is of great interest to me.
Whether or not they are separate datastores in separate formats is an implementational detail. The separation in code *allows* them to be separate but they do not have to be. Having it in this way allows for easily separating them at a later point if you desire but you don’t have to start with them in this way.
Thanks again,

Explore related posts