QCon San Francisco 2008 - Unleash Your Domain

Erik Rozendaal

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.

Comments (7)

  1. Lars Vonk - Reply

    November 22, 2008 at 10:41 pm

    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?

    Lars

  2. Serge Beaumont - Reply

    November 23, 2008 at 10:59 am

    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... :-)

  3. Erik Rozendaal - Reply

    November 23, 2008 at 6:19 pm

    @Lars: Yes, that's a possible, but not necessary, implementation. Greg Young uses separate data stores to achieve high scalability. He calls his read-only database a reporting database. But it isn't just used for reports, it is also used to populate data on the UI, etc. Many applications may not need this additional complexity.

    @Serge: actually, taken to its extreme the domain model is only concerned with updates, the interesting stuff. Because reads are separate, your "update" domain model becomes simpler and there is less pressure to break encapsulation to support query operations. No longer do you need to change your ORM mappings to avoid client lazy initialization exceptions (yes, this stuff happens!) So potentially your domain model becomes simpler and more cohesive, although overall system complexity may increase due to the separated read support.

    Finally, by explicitly turning your (procedural) service methods into immutable message objects you also reduce the need complex stuff like AOP. Transactions can now be handled inside a single method that accepts incoming commands for the domain.

    Very interesting stuff to explore further, I think.

  4. [...] 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 [...]

  5. Sérgio Silva - Reply

    November 26, 2008 at 12:19 am

    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!

  6. Erik Rozendaal - Reply

    November 26, 2008 at 1:26 pm

    The slides can be downloaded: http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides//GregYoung_Unshackle_YourDomain.pdf

    However, it mostly consists of pretty pictures and is a bit light on details. Hopefully the recorded presentation will be available sometime soon.

    In the meantime, check out this talk: http://codebetter.com/blogs/gregyoung/archive/2008/05/20/devteach-talk.aspx that seems to cover many of the same ideas.

  7. Greg Young - Reply

    January 12, 2009 at 6:52 pm

    Erik,

    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.

    @Lars
    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,

    Greg

Add a Comment