Domain driven design and WCF services architecture

Question

I am trying to figure out how to architecture my project in the DDD paradigm (a complete beginner in DDD) and stumbled upon a problem about the implementation of the web services... These are some options that I see:

Fat client, Fat server (option 1):

• Server:
  • Repository layer: talks to database and can return domain objects.
  • Domain layer: contains domain objects with business logic and validations.
  • Service layer: acts like a façade to the domain layer.
  • WCF layer: exposes the service layer to web methods. It maps domain objects to appropriate DTO objects.
• Client:
  • Infrastructure layer: talks to server through WCF services. It maps DTO objects back to domain objects.
  • Domain layer: contains domain objects with business logic and validations.
  • Service layer: acts like a façade to the domain layer.
  • UI layer (WinForms): uses service layer to communicate with domain objects.

Good: because the domain layer is both on client and on server, the validations happens on both (good for clients - reduces number of calls to the server, good for server - because of 'never trust the user data').

Bad: validation happens twice, a lot of mapping needed (for example a simple query to the database: domain (returned by repository) -> DTO (needed for WCF) -> domain (needed by domain layer on client) -> DTO (for WinForms). Any change in the domain should be deployed to server and client at the same time. Complicated?

Fat client, thin server (option 2):

• Server:

  • Repository: talks to database and returns DTO objects.
  • WCF layer: exposes the database calls to web methods.

• Client: Exactly the same as in option 1.

Good: on the client I can treat WCF services as a regular repository which returns DTO objects. Simpler as option nr. 1.

Bad: is it OK that the repository works on DTO-s instead of domain objects? Also - server doesn't perform any validation so it has to trust clients about the data.

Thin client, fat server (option 3):

• Server: Exactly the same as in option 1.

• Client:

  • Infrastructure layer: talks to server through WCF services.
  • UI layer (WinForms): uses presenters to communicate with the server via WCF calls in infrastructure layer.

Good: all domain logic is on the server.

Bad: the client doesn't contain any validation, so it can make a lot of unnecessary calls to the server.

---

I am leaning toward my first option, but it looks like I am overcomplicating things... Any advice or other options?

Answer 1

I'd go with Option 3, with the following notes:

1. Try and reduce the amount of domain logic that your clients need to know to get the job done. Create services that expose that data in meaningful (to your clients) ways, so that you can request collections of domain objects which fulfil certain criteria, rather than doing that crunching on your client.
2. Validation should be considered optional on the client-side as, you can never guarantee that future client implementations are going to be done properly. Therefore, always validate on the server side as if it hadn't been done elsewhere. Of course, clients should be validating on the client-side too.
3. Rather than mapping the WCF data back to full domain objects on the client side, consider mapping them to simpler ViewModel-type objects - a slimmed down version of your full domain objects only containing properties appropriate to the client - makes client programming simpler.

The problem you're still faced with is lots of mapping. I guess this price is worth paying (and made easier with a tool such as AutoMapper) because removing the client dependency on your domain model gives you breathing room to change your domain, tweak the mapping, without breaking any client code.