Greg Young [MVP]

Sponsors

The Lounge

News

Advertisement

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.


Posted 07-15-2009 4:21 PM by Greg

[Advertisement]

Comments

Mark Miller wrote re: Unshackle Your Domain
on 07-16-2009 1:11 PM

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.

Greg wrote re: Unshackle Your Domain
on 07-16-2009 2:54 PM

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

Carl-Johan Wik wrote re: Unshackle Your Domain
on 07-18-2009 4:32 AM

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.

Frank wrote re: Unshackle Your Domain
on 07-22-2009 6:52 AM

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.

Greg wrote re: Unshackle Your Domain
on 07-22-2009 8:49 AM

@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 wrote re: Unshackle Your Domain
on 07-22-2009 9:11 AM

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

Add a Comment

(required)  
(optional)
(required)  
Remember Me?