Tip on employing the domain model pattern

Today, I read Udi's latest article about domain model pattern published in MSDN magazine. I want to comment on following part of the article:

When designing a domain model, spend more time looking at the specifics found in various use cases rather than jumping directly into modeling entity relationships—especially be careful of setting up these relationships for the purposes of showing the user data. That is better served with simple and straightforward database querying, with possibly a thin layer of facade on top of it for some database-provider independence.

Udi couldn't be more right here. I had similar dilemma few weeks ago,and my reasoning happened to be same as Udi's. I had an association that seemed so natural and correct. Association was as follows:

But after looking deeper at problem I was trying to solve it turned out that this association was only needed for presentation purposes. So I dropped the association altogether from the domain model. Presentation issue was solved by using a simple query (using NHibernate). This shows that domain model should be used for capturing core business behavior only. In the article Udi also wrote about Domain Events pattern that can help solve complex problems quite elegantly. I strongly recommend reading this article.