Udi Dahan has yet another good read in MSDN Magazine, where he talks about the . I particularly like a couple of things about it. One is a comment about what the domain model is not:
If you had come to me a few years ago and asked me if I ever used the domain model pattern, I would have responded with an absolute "yes." I was sure of my understanding of the pattern. I had supporting technologies that made it work.
But, I would have been completely wrong.
….the No. 1 most common fallacy about employing domain models. I myself was guilty of making this false assumption for a number of years and see now where it led me astray.
Fallacy: Any persistent object model is a domain model
First of all, a persistent object model does not inherently encapsulate all the behaviors of the business that are likely to change. Second, a persistent object model may include functionality that is not likely to change.
This is a confusion that I’ve seen come up in a number of different ways. At one of our Chicago Alt.NET meetings, we did a fishbowl session that revolved around DDD and whether it was worth it
(or something like that), and a number of people seemed to make the mistake of thinking that if you started off with POCO classes and/or left database design considerations off till the end, then you were automatically doing DDD, which isn’t the case (this isn’t to suggest, of course, that starting off with POCO classes, etc. is therefore bad).
Udi highlights a part of the domain model pattern that doesn’t get a lot of attention. It isn’t just that a domain model has incorporates both behavior and data, it is also that it incorporates behavior that is subject to a lot of change.
Now, one can obviously argue what constitutes ‘a lot’ of change versus a little, and we can quickly get to ‘how many angels can dance on the head of a pin’ territory, but I think it is important to highlight that doing domain driven design is really much more complicated than it is sometimes described to be.
The other thing I really like about the articles is this diagram:
![fig03.gif]()
The right-side of the diagram shows what might be shown to the user, which does not require you to go through the domain model. How the data gets to the screen is open to a number of possibilities (I would prefer DTOs), but the general idea is that you don’t need to try to create a domain model that encompasses all aspects of your architecture. Instead, you can focus on the left-side of the diagram, where actions taken by the user flow down through the domain model (typically, this might be done through commands/events that take the form of messages).
In any event, it’s a good read. Check it out.