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?
Best Answer
I'd go with Option 3, with the following notes:
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.