Geeks With Blogs
Mike Nichols - SonOfNun Technology If I were the captain on a big steamboat...

Just starting out digging deep into Domain Driven Design (DDD) and reading thru Jimmy Nilsson's book Applying Domain-Driven Design and Patterns has the same side effects on me that happen whenever I learn something new about software...fuzz.

It's good fuzz but I am confuzzed about what seem to be contradictory ideas by the gurus Fowler/Evans on this topic. First, we are told NOT to remote. Fine. Then in Fowler's PoEAA book we are told (by Randy Stafford) to consider very before implementing dumb data containers such as Data Transfer Objects (DTOs). Fowler makes mention of these objects in context of remoting. The primary purpose of these objects is to reduce the number of calls during expensive remote operations...the java community still fights battles over whether to use these or not. These are a kind of anti-pattern that emerged to deal with serializing objects on javas platform across the wire (this isn't an issue any more I think), but emerged as having a usefulness apart from that. The real involvment of using these objects is the accompanying assemblers/converters/mappers that are required to construct them. It can get hairy (like all good fuzz). Especially when you start to deal with associations between them.

All this is very clear to me. Until I understand that it is best to protect the Domain layer and not use domain objects directly in your presentation layer. now I am hearing this: Don't use DTO's but don't use your Domain Objects, either. So now my entire website has just a header and a footer. Just kidding.

Now third and fourth alternatives are presented too in Nilsson's book by Mats Helander in which you essentially wrap or map (using perhaps an O/O mapper) your domain object for delivery to your presentation. He is presenting what Fowler calls the Presentation Model (PM) I think...but I just don't see the difference between these objects and the DTOs. The PM now has its own life that is catering to the view's needs while interpreting the Domain Model...but how is this different from dealing with the assemblers and so on with DTOs?

So I set out to write a Service Layer/Application Layer but find I need to also layer a Facade on top of THAT layer to convert my Domain Objects to DTOs. Then my presenter (MVP) takes over and we are hunky dorey. So I pretty much have a one-to-one relationship to calls between my presenter --> facade --> service layers (in that order from the UI).

I really like the idea of not having Domain objects in my Presenter since there seems to be a looser coupling between my UI and Domain. Plus I use Notification to communicate activities in my lower layers up to my UI where I have automate the messages in my Master Page ... I never have to touch it. I don't want notification stuff in my Domain Objects which would seem to be a requirement if I were to return Domain Objects to my presentation.

But I also like SIMPLE. The sirens of Domain Objects in my presenter call out, but they seem to be deceiving me. What other folks out in .NET land have applied DDD and how have you shielded your Domain from your presentation layer?

Posted on Tuesday, August 15, 2006 4:13 AM OOP, Patterns, Architecture | Back to top

Comments on this post: Accessing Domain Driven Design via .NET layers and meditations on fuzz

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Mike Nichols | Powered by: