How can DDD be applied to smart clients?

Question

Almost all examples of DDD within the Alt .NET community are applied to web development; what I would like to see are some examples of DDD applied in scenarios where the client handles most of the business logic and the server is simply a web service for CRUD using DTOs [1].

I'm currently working on a product that has an anemic domain model. Coming from years of web development, this sort of thing would typically make me cringe; however, I'm not sure how I would go about structuring this code around the DDD principles. In a web app, I have direct access to the database at the point where I handle business logic (implemented within my domain model, invoked by the controllers), which means that I can easily have a rich domain model and use an ORM for CRUD. But, in my current project, DTOs are the only sane way to transfer data. 80% of the business logic is implemented in View Models (this is a WPF app), the other 20% percent is located in stored procedures - and 100% of the DAL is hand written ADO .NET. There's really isn't a lot of business logic implemented within the web services, so there aren't any "entities" to be found in the solution - they're all DTOs.

How could I introduce DDD into this sort of client/server architecture? What sort of experiences have you had, and what approach did you take? What patterns would you suggest? I haven't had much time to grok CQRS, but something tells me it could related - is that so?


Foot notes

1. Perhaps this is the wrong question to be asking. In this type of client/server WPF scenario, would it make sense to follow the web app paradigm, where 99% of the client's focus is on display logic?

Answer 1

This is funny, because I often wonder how DDD can be applied to web development.

I don't mean this to be a comprehensive answer to your question, but you might find something useful among the responses to an old question of mine: http://stackoverflow.com/questions/2201150/should-i-map-a-dto-to-from-a-domain-entity-on-both-client-and-server-sides

As a very general answer to your question, I'd say that you could move logic out of the view models and into a client-side domain model (since it sounds like the server side is working just fine without any concept of a domain model). You'd use the DTOs coming out of the web service to "hydrate" these entities.

If you're creating a smart client, then you want to leverage the ability to maintain state and perform logic directly in the client (so, "no" to the footnote).