Unshackle Your Domain

Many people have asked me for links to this video. It has been up on infoq for a week or two now. http://www.infoq.com/presentations/greg-young-unshackle-qcon08 this is from last fall in SanFran for QCon.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

9 Responses to Unshackle Your Domain

  1. Rajesh M says:

    Hi Greg,

    Thanks for the wonderful presentation. Can you explain the “Rolling Snapshot” concept in detail if possible with some implementation detail. I would really like to know.
    Thanks for your help in advance.

  2. Andy says:

    Great presentation! Love it!

    A few questions:

    The commands does not have any return value (void) but how can i tell the user who just entered an action that it was “allowed” or “successfull?” or if an exception occured?

    Should perhaps pass a long a GUID in the command that I then frequently poll (using a separate query) get the final result?

    How/where would you handle the input validation? (command argument validation). Would you create a “command proxy” in the client that knows how to validate them?

    Are there any public open source project that implements CQS that you can recommend us to have a look at?

    Last request, could you help the world by answering this unanswered question? :-)


  3. Zilvinas says:

    Sending emails is an interesting question. To me sending an email is a report. So that would have to be on the query side?

  4. Greg says:

    @Frank you replay events not commands. As such you dont have any actions being performed (you are just remembering that the action was performed).

  5. Greg says:


    “Why not use the build in technology in the database for this, why build it your self? I can see that the representation of the data can change in the write an read database, but still you can you the database replication for this.”

    Because you will in a good sized organization often have 5-10 different models of the same data. Also by handling explicitly you can control things like SOAs. You are a large online retailer, you have two sales in a resource constricted environment one is for a 1,000,000$ sailboat and the other is for a $2 coffee cup … who gets priority? What happens when we start having SLAs on the data being sent to the other models? When you are breaking SLAs which are ok to break vs not ok? How do we build that logic into the databases logshipping? Also to go with this I have yet to see a log shipping that really supported changing the data in terms of model or allowing for 10 databases to ship to a single reporting model (but it could be done) …. for the business value side it cant be done well because domain concepts would leak.

  6. Frank says:

    Greg, thanks for the presentation, it is all very interesting information.

    When replaying your commands, do you use exactly the same code or do you disable certain things? For example, when an order is submitted with a SubmitOrder command, eventually an e-mail would be sent to the customer with an expected delivery date for example. You wouldn’t want to send that every time you replay your commands.

  7. Carl-Johan Wik says:

    Where nice presentation. Some questions:

    I have view objects in my systems as : property part is my messages and the method are the services. Some would say a service oriented architecture. When I look at DDD and the talk about not using getters and setters, then the object should only have methods. Isn’t that a service object then,isn’t this the same as service oriented design?

    It make sense to me to only send the change of the data/state and not the state itself. But isn’t this what for ex. what the database is doing in log-shipping “replication” between a online(write) database and a report(read) database. Why not use the build in technology in the database for this, why build it your self? I can see that the representation of the data can change in the write an read database, but still you can you the database replication for this. The same about undo/redo can be done with the transaction log in the database. Why build this and have this in the “application” layer and not let the database take care of this? Would be interesting to see your view on this.

  8. Greg says:

    There are generally 3 ways of handling this…

    The first is to keep your SLAs low enough that it is reasonable (say under 30 seconds). Since you can detect failures this is usually ok for users as it won’t happen very often.

    The second is to trick the user that made the change (more common in smart clients) by “pre updating” his presentation model with the change you know will be present. This can be problematic because it causes th logic to be duplicated in the presentation model

    The last method similar to #1 is to just manage user expectations.

    Overall I tend towards #1 and try to keep my UI model within 15 seconds of my transactional model (whcih is a reasonnable goal for most systems).

  9. Mark Miller says:

    This was one of the best presentations I’ve seen. But I have a question about the read-only/write-only repositories and the UI screen described in the presentation.

    I’ve worked on applications which were similar to this, but we had a “reporting application” and a “data entry” application. The reporting application was eventually consistent, but the data entry application reflected the current state of the data model. If all queries are reports and come from the report store, which is eventually consistent and the domain store is write-only, how do you show the user the data they just entered if they can’t read from the store they just wrote to?

    An example would be if the user navigates to a screen, updates it, changes screens, then navigates back to the screen where they just modified the data? Is this just about managing user expectations? Or do the user’s changes need to live in memory/cache somewhere for a limited time?

    Again, I loved the presentation. I’ve always believed DDD was for LOB applications with smaller scale, but after this I’m getting a better vision.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>