Comments on: DTO’s, DDD & The Anemic Domain Model http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/?utm_source=rss&utm_medium=rss&utm_campaign=dtos-ddd-the-anemic-domain-model Sun, 12 Feb 2012 18:54:00 +0000 hourly 1 http://wordpress.org/?v=3.0.5 By: Marty Nelson http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/comment-page-1/#comment-63683 Marty Nelson Tue, 15 Feb 2011 16:29:00 +0000 http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/#comment-63683 This seems to just be a lot of confusion about transactional vs analytical services. Domain models are largely based on transactional (CRUD and workflow) type uses. Asking a question like 'display the top 10 products' is an analytical use case that transcends the specific entities of the domain model to deliver additional insights and knowledge. One common pattern is to combine and encapsulate an analytical use case with a subsequent retrieval of the domain entities indicated by the analysis. This is only useful if the purpose is to consume those entities in a transactional manner. But, as you mention, this is a waste for many analytical use cases. The two approaches I see most often are to either create light-weight domain entity proxies, i.e. ProductInfo, or to serve up analytical data as something completely different but entirely consistent across the board so it can be consumed uniformly by analytical tools, for example in the Windows world serving up oData so it could be consumed by excel, SharePoint, etc. This seems to just be a lot of confusion about transactional vs analytical services.

Domain models are largely based on transactional (CRUD and workflow) type uses.

Asking a question like ‘display the top 10 products’ is an analytical use case that transcends the specific entities of the domain model to deliver additional insights and knowledge.

One common pattern is to combine and encapsulate an analytical use case with a subsequent retrieval of the domain entities indicated by the analysis. This is only useful if the purpose is to consume those entities in a transactional manner.

But, as you mention, this is a waste for many analytical use cases. The two approaches I see most often are to either create light-weight domain entity proxies, i.e. ProductInfo, or to serve up analytical data as something completely different but entirely consistent across the board so it can be consumed uniformly by analytical tools, for example in the Windows world serving up oData so it could be consumed by excel, SharePoint, etc.

]]> By: Jonathan Oliver http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/comment-page-1/#comment-50380 Jonathan Oliver Mon, 16 Nov 2009 13:46:23 +0000 http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/#comment-50380 I recently wrote about the various data access mechanisms (NHibernate, Entity Framework, LINQ to SQL, etc) and how they relate to a read model: http://jonathan-oliver.blogspot.com/2009/11/cqrs-reporting-database-access.html I recently wrote about the various data access mechanisms (NHibernate, Entity Framework, LINQ to SQL, etc) and how they relate to a read model:
http://jonathan-oliver.blogspot.com/2009/11/cqrs-reporting-database-access.html

]]> By: Jan Van Ryswyck http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/comment-page-1/#comment-50350 Jan Van Ryswyck Sun, 15 Nov 2009 19:47:12 +0000 http://elegantcode.com/2009/11/13/dtos-ddd-the-anemic-domain-model/#comment-50350 Check out this post from Greg Young on the matter: http://codebetter.com/blogs/gregyoung/archive/2009/07/15/the-anemic-domain-model-pattern.aspx Check out this post from Greg Young on the matter:

http://codebetter.com/blogs/gregyoung/archive/2009/07/15/the-anemic-domain-model-pattern.aspx

]]>