Domain-Driven Design – Is a Domain Service Just a Facade or Mediator Pattern?

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.

Are Domain Services merely an Interface which exist to provide a layer of abstraction between the Infrastructure Layer and your Model? ie: Repositories + HashingServices, etc.

Domain services responsibilities include several things. The most obvious is housing logic that doesn't fit into a single entity. For example, you may need to authorize a refund for a certain purchase, but to complete the operation you need data from the Purchase entity, Customer entity, CustomerMembership entity.

Domain services also my provide operations needed by the domain to complete its functionality such as PasswordEncryptionService, but the implementation of this service will reside in the infrastructure layer since it will mostly be a technical solution.

Infrastructure services are services which so an infrastructure operation such as opening a network connection, copy file from file system, talk to an external web service or talk to database.

Application services are the implementation of a use case in the application you are building. If you are cancelling a flight reservation you would:

1. Query the database for the Reservation object.
2. invoke Reservation->cancel.
3. Save object to DB.

The application layer is the client of the domain. The domain has no idea what your use case is. It just exposes the functionality through its aggregates and domain services. The application layer however mirrors what you are trying to achieve by orchestrating the domain and infrastructure layers.

I mentioned having an Application Service which looks like this: Access/Application/Services/UserService::CreateUser(string name, string email, etc): User The method signature accepts primitive data type arguments and returns a new User Entity (not a DTO!).

PHP might not be the best place to start learning about DDD since many of the PHP frameworks out there (Laravel, Symfony, Zend,..etc) tend to promote RAD. They are focused more on CRUD and translating forms to entities. CRUD != DDD

Your presentation layer should be responsible for reading the form inputs from the request object and invoking the correct application service. The application service will create the user and invoke the User repository to save the new user. You may optionally return a DTO of the user back to the presentation layer.

How should separate modules handle unidirectional relationships. Should module A reference module B's application layer (as it's doing now) or the infrastructure implementation (via separated interface)?

The word module in DDD lingo has a different meaning than what you are describing. A module should house related concepts. For example, an order module in the domain layer could house the Order aggregate, OrderItem entity, OrderRepositoryInterface and MaxOrderValidationService.

An Order module in the application layer could house the OrderApplicationServie, CreateOrderCommand and OrderDto.

If you are talking about layers then each layer should preferably depend on interfaces of other layers whenever possible. The presentation layer should depend on interfaces of the application layer. Application layer should reference interfaces of the repositories or domain services.

I personally don't create interfaces for entities and value objects coz I believe interfaces should be related to a behavior, but YMMV :)

Do Application Layer Services require a Separate Interface? If the answer is yes then where should they be located?

It depends :) for complex applications I build interfaces coz we apply rigorous unit, integration and acceptance testing. Loose coupling is key here and the interfaces are in the same layer (application layer).

For simple app I build against the app services directly.