Reputation: 6317
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
Upvotes: 1
Views: 624
Reputation: 57959
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: 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).
Upvotes: 0