Accessing Domain Driven Design Class LIbraries from a WCF Service

I need some help clarifying how I should be setting up my project. My solution structure is as follows:

Company.DataTransferObjects
--AdminDTO.cs
--CustomerDTO.cs
Company.DataTransferObjects.Helpers
Company.Infrastructure.DomainServices
--Admin
---AdminService.cs
--Customer
--CustomerService.cs
Comapny.Infrastructure.Repositories
--Admin
---AdminRepository.cs
--Customer
---CustomerRepository.cs
Company.Domain
--Admin
---Admin.cs
---IAdminRepository.cs
--Customer
---Customer.cs
---ICustomerRepository.cs
Company.WebServices
--WebApi.cs
--IWebAPI.cs

My questions are as follows:

1) Does my set-up look right to you?

2) DTOs. From the web service's perspective, where should the DTOs be created? Should I be creating the DTOs in an independent class library and referencing them from the WebService or should they be part of my web service project?

Also, it is not clear开发者_开发知识库 to me how my DTOs should be interacting with my Domain objects. Can somebody please explain their purpose from a program flow point of view and, specifically, if you were creating a WCF service how you would be manipulating them?

3) Domain Services. I am still having a hard time wrapping my mind around the purpose of Domain Services. Is this what is exposing the operational functionality that is not hitting the database and requires repository methods that cannot be accessed directly? In other words, is a Domain Service a method that manipulates multiple repository methods? So, if my WCF service is calling data that can be accessed via a repository method, then that is what it should do. But, if it requires data that is the result of multiple repository methods, then this should be done via domain services?

4) Where does the Facade Pattern fit in a the DDD architecture?

Please excuse my confusion, I am trying to understand. It would be a serious help if you could tell me "what" I should be accessing from my WCF service.

Thanks!

---

going in reverse order on your questions:

4) Your web services are a facade to your domain, effectively.

3) Domain services can hit the DB too, they're typically the main API that consuming code should use to talk to your domain on anything that involves more than a single entity, or for things that represent a series of transactional steps. Some folks consider Repositories to be a special case of Domain Services (Rather than being an either/or). I usually consider my Services to be my domain's public interface.

2) DTO's are normally useful when you are (or plan to eventually) crossing physical boundaries. Anytime you think you might need to serialize something (e.g. into a SOAP message), you want to think about a DTO. SO in your case, your WCF project would use DTOs as its DataContracts, but internally it might use your domain objects (unless you expect your domain to sit in a different app domain or on a different physical box).

1) It's all personal preference; your layout doesn't look unreasonable, though it's different than how I normally organize.