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.
-
Archives
- April 2014
- March 2014
- February 2014
- November 2013
- September 2013
- July 2013
- May 2013
- March 2013
- February 2013
- January 2013
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- October 2009
- August 2009
- July 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- August 2007
- July 2007
- June 2007
- May 2007
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
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.
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?
http://stackoverflow.com/questions/1476886/how-to-implement-cqs-with-in-memory-changes
Sending emails is an interesting question. To me sending an email is a report. So that would have to be on the query side?
@Frank you replay events not commands. As such you dont have any actions being performed (you are just remembering that the action was performed).
@Carl-Johan
“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.
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.
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.
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).
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.