Some time ago I left comments on a couple of pages, here and here: http://www.codeplex.com/AppArch/Wiki/View.aspx?title=Web%20Application%20Archetype and http://www.codeplex.com/AppArch/Wiki/View.aspx?title=How%20To%20-%20Design%20Business%20Entities.
The gist of the comments was that it would help to clarify the way the Domain Model pattern is presented in this guide. I'll copy the comments in here:
From Web Application Archetype
"How does this archetype address the Domain Model pattern (as in
I raise this for two reasons:
(a) Due to its visual layout, the diagram implies that business logic is something that data passes _through_; rather than something that data is encapsulated _with_.
(b) The bullet points under “Business Layer Considerations” seem to imply that business logic is best written as stateless routines, separated from the data entities. That is exactly the case in Table Module and Transaction Script patterns, but it is not the
case in the Domain Model pattern.
With the introduction of LINQ-to-SQL, the Domain Model pattern is more approachable for .NET developers than ever before, so it would be great to see the pattern presented here -- not as the only way to do things, but as a valid option on the Microsoft platform."
From How to: Design Business Entities
"The introduction says: "They should not contain any data access or business processing logic" - but the second half of that sentence is at odds with the subsequent (and correct) description of the Domain Model pattern.
How is "Domain Value Objects" different from the "Anemic Domain Model" :
Would Domain Value Objects necessarily be used as the primary entity structure for the application? I would have assumed not, and rather expected that their use would be limited to cases where remote calls were involved. Reasons are as per:
Is it accurate, in general, to say that the Domain Model "typically does not map to relational models used by most databases"? I like the earlier suggestion that ADO.NET LINQ is a good default choice. In cases where you control both the data model
and the object model, for instance when building a new system and DB from scratch,I believe you can make them similar enough that you can implement the Domain Model pattern well (even with the mapping limiations imposed by LINQ to SQL). So, is it correct to
say the the Domain Model pattern typically doesn't map well to relational DBs? Or would it be more accurate to say that it "may not map easily to _legacy_ relational database structures"?