Billy McCafferty - All Comments

re: Bridging the Communities

Neo — Fri, 12 Mar 2010 00:11:24 GMT

re: Better Application Services and CQS using S#arp Architecture 1.0 Q3 2009

Chris F — Thu, 11 Mar 2010 22:01:17 GMT

This is fantastic. I've been using S#arp Arch on a corporate back-end system for a year, and have had to do some of these changes myself. However, the CQS stuff with the SPs via NHibernate is pretty awesome, as is the acknowledgment for better DTOs integration.

Great job.

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

Thu, 11 Mar 2010 13:01:28 GMT

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

Billy McCafferty — Tue, 09 Mar 2010 20:10:24 GMT

Exactly! ;)

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

corey coogan — Tue, 09 Mar 2010 17:25:30 GMT

So as usual, it depends.

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

Billy McCafferty — Tue, 09 Mar 2010 16:32:11 GMT

Great discussion here!

@Joe,

After considering it further, and in light of well written arguments to this effect, I moved repository interfaces back to .Core for domain services to consume.

Repositories need to be able to return reporting objects (as DTOs), which flatten the domain model. If not, then you may end up traversing an immense amount of the domain model to simply show a few columns on a listing page. If you allow a repository to return a DTO to encapsulate the reporting information, then this can reduce potentially hundreds - if not thousands - of queries, into one.

@Martin,

Terrifc explanation!! In light of the way you describe, the DTOs in the domain layer could be called "QueryDtos" to better represent exactly why they exist.

@James Broome,

These are great arguments that have me thinking. My gut reaction is that application services should not be platform-specific...or at least not know that they are. In other words, I believe that application services are *ideally* platform agnostic. With that said, there's a difference between what's ideal, what's practical, and what the expectations are for the front-end platform to differ. E.g., if it's known from the get-go that multiple front ends will be communicating to the application services (ASP.NET, ASP.NET MVC, WCF, RESTful services), then application services should only expose objects which are platform agnostic and easily serializable with likely no direct exposure of the domain layer itself. On the other hand, if you're creating a CMS which inherently deals with *how* information is displayed, not just *what* information is to be displayed, then objects will inevitably carry such information all the way up through the layers from the repositories. So I can see complete validation of your arguments, but in context of the needs of the application. This is one of the immense challenges of creating an application framework (S#arp) which is opinionated enough to get people going very quickly, without being too preferential to a particular application type.

@Peter,

I agree that it's quite likely that different consuming clients would require different information to be displayed. With that said, the information would either be gathering directly within the consuming client (e.g., within controllers using repositories directly) or by adding additional application services which expose the needed information for consumers. With smaller projects, I believe that controllers communicating directly with repositories is a great approach and keeps things simple. With that said, if it's expected that the application is going to get quite larger, I've shot myself in the foot a couple of times by not having a proper separation between the front-end (which includes the controllers) and the application services, or "surface area," of the application.

@corey coogan,

I can see valid arguments for having domain services interact with repository interfaces. But as a rule, I find that the more objects in the domain layer which interact directly with repositry interfaces, the harder it is to maintain and keep a clean separation of concerns. For S#arp 1.5, we've ended up keeping the repository interfaces in the .Core layer (mostly for upgrading concerns), but also to accommodate the needs of domain services which may need to interact with repositories and/or for simpler applications which do not require such austere separation measures.

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

corey coogan — Tue, 09 Mar 2010 16:02:26 GMT

Great post Billy. Concerning your last point, specifically "Ideally, repositories would not be used by domain objects", would you mind adding a little more here.

I realize that when I'm using NHibernate, my app service can load up an aggregate root and interact with those behaviors. Assuming I have lazy loading enabled, my object could typically go without accessing a repository interface.

What about cases where my domain object has operations that may or may not need real time data? How do you handle that? Do you just handle this through lazy loaded objects and composition? It's often times very enticing to just have a repository for a case where you need check inventory or something like that.

I had discussions with Vauhn on the DDD group the other week about this same thing. I was defending the Repository interfaces in Core while he keeps them with his service layer, much like you are describing.

Thanks,

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

Peter — Tue, 09 Mar 2010 15:45:23 GMT

To me, the ViewModel doesn't make sense in the application services layer since "what should be displayed" may be different depending on the consuming client. That's not a concern I'd want the "surface area" of my application to have. Rather, I'd have it concerned with the relevant information to accomplish some task. This is a subtle difference. We don't want to say what _should_ be displayed in the view. We want to provide a report on the state of the application to support the client in making decisions.

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

James Broome — Tue, 09 Mar 2010 10:36:15 GMT

Billy,

I disagree with the statement about view models, that they are solely describing 'what' should be displayed and not 'how'. I still believe that view models are totally presentation specific (as I stated in the Sharp Arch discussion that led to this post) and therefore should live with the Controllers - i.e. with another presentation layer, the controllers and view models would be replaced. I'd like to give some real world examples to back this up.

1. On the Fancy Dress Outfitters project, we had a requirement to be able to "theme" parts of the site. This would be controlled in a content management system, however our CMS definitions and content items were treated as as domain objects just like any other entity - i.e. to build up a view you needed data from a product database and data from a CMS database. All this was bound to a view model to build up the view. In this case, themeing was controlled via CSS files and utimately it was up to the application to translate the selected theme into the path for the CSS file. This file path was passed into the view to be rendered out in a <link> element in the HTML.

2. On the same project (and every other web project I've worked on) we've added Google Analytics code to the web page. The Google Analytics account ID is stored in some form of configuation source (web.config, database etc) and so needs to be passed to the view in order to render the analytics javascript code. We pass through the analytics code to as part of the view model.

3. All public web pages should specify meta data, page titles etc. This isn't always an exact copy of other pieces of view data - e.g. meta descriptions could come from CMS sources, or extracts of page content etc. Again, this is all passed into the view via the view model.

What I'm getting at is if we agree that a view should be as "dumb" as possible, and be given everything it needs to display, then there are numerous situations where a view model contains information on "how" something is being rendered, or more specifically in these examples, be tied in to a particular presentation context (an HTML page). If I was to build a WPF presentation layer on top of my application, then all the examples above would be redundant. This would mean either refactoring my view models to try and maintain all types of presentation specific properties, or accepting that view models are tied to a particular presentation layer (and therefore live with the controllers).

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

Martin Aatmaa — Mon, 08 Mar 2010 22:20:26 GMT

"If the repository interfaces are maintained in .ApplicationServices, then DTOs may be maintained in a cleanly separated library without worrying about the line between DTOs and domain objects being grayed. But data interfaces (and DTOs) may be maintained in .Core if the team feels the simplification is warranted."

I have found it beneficial to make a distinction between two "types" of DTOs:

1) DTOs that serve to decouple the Domain (.Core) and the View.

2) DTOs that serve as a complement to the Domain (.Core) and represent flattened read-optimized views of the domain

In the case of 1), these DTOs should be maintained either in the Controllers layer, or in the ApplicationServices layer (if more than one client is able to share the same DTO). These DTOs would be populated by automapping domain entities to and from the DTOs. These DTOs would not be known to the Domain layer (including the Repo interfaces in the Domain layer).

In the case of 2) these DTO's should be maintained in the Domain layer. They would be populated via Repos (whose interfaces live in the Domain layer), and can be consumed directly via the View/Client layers.

The latter type of DTO is treading the CQRS territory. Looking forward to seeing that pattern set gain more traction, as I see a lot of simplification possible there.

dotNET News

Cadred (dotNET) — Mon, 08 Mar 2010 16:55:20 GMT

dotNET News

A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns - Billy McCafferty - Devlicio.us - Just the Tasty Bits

9eFish — Mon, 08 Mar 2010 02:57:47 GMT

9efish.感谢你的文章 - Trackback from 9eFish

S#arp Architecture in 2010

Alec Whittington — Sun, 07 Mar 2010 22:41:28 GMT

So it has been rather quiet on this blog for quite sometime. I could give you the same old excuses that

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

Joe Wilson — Sun, 07 Mar 2010 00:47:04 GMT

I nodded in agreement the whole way through.

My personal preference is view models that don't reference to the domain model. You're right to point out the overlap and duplication this causes, but I see them as separate concerns and easily translated with AutoMapper in the application services layer. One is the internal application model and the other is the external usage in the UI layer.

I'm also glad to see the new emphasis on the application services layer. I like keeping my view models in that assembly. The consuming UI has to have a reference to that assembly anyway.

I'm still digesting the idea of repository interfaces in the application services project instead of core. I haven't run into the DTO problem you describe, but my repos return domain entities, not DTOs, and I haven't needed to separate out DTOs into an isolated assembly yet. If I needed WCF integration, I would decorate my view models and app services with WCF attributes. But in my mind, view models are just DTOs on the way to or from a view in the UI.

re: A Few Thoughts on DDD, DTOs, View Models, Repositories and Separation of Concerns

Billy McCafferty — Sat, 06 Mar 2010 21:33:59 GMT

Fair enough...I removed "CQS from the post title. ;)