The structure that you propose is quite similar (mutatis mutandis) to one of our application that was deployed in production 2 years ago. It works, but you have to carefully design the domain model, separating in different bounded context the various aspect of the application.
So these are my own answers:
- No, there's no "best-practice" to conform here. After 5 years of DDD practice in financial applications, my own opinion is that DDD is still a research field. However, it proves very well if applied correctly to projects whose value resides in the experience of a domain expert. However you have to distinguish business needs (that are relevant to the domain) and technological requirements (that can help drawing the components and tiers that your application needs)
- Business Layer (if you need to identify one) should handle the business rules only. It's the layer of the domain models, in a DDD application.
- In my experience, if you can trust the client machine and you correctly design the domain model, you should not need any Application Server, at all. However, if you really need it (for example because clients cannot connect to the db), I would make it as simple and stateless as possible. An useful consideration here is that most of times, the business rules already prevent concurrent access to mutable entities. Don't try to handle concurrent access to such entities in that case, simply build a mutual exclusion mechanism.
- For inter-process comunications, use only DTOs. You can choose, however, to move the whole domain into the Application Server (that will become much more complex and stateful), and use a simpler MVC pattern in the client. This is simpler from the client's developer point of view, but more expensive overall (in particular, it can be hard to scale).
- Simple type validation of input fields can be done in the view (integers, date times and so on), but you should model each relevant type of value with a custom value object before passing it to the domain. For example you should never pass strings or decimal to domain objects, but Email or Money. Moreover the domain in the only responsible for business invariant: it should throw expressive exceptions when an operation can not be performed.
- DTO are more expressive, thus easier to debug.
Before you start, I think you should ask yourself some questions:
- Do I need a domain expert or I can learn enough of the business by reading Wikipedia or a set of well written specifications? Tip: no need for (at least) a domain expert == no need for DDD.
- Can I trust the machines where the client will be deployed? If you can't, you should consider moving the domain into the Application Server (and adopt an MVC pattern client side to handle WCF requests and DTO bindings).
Finally, if you really need DDD, and you are new to it, you could find the Epic's modeling patterns useful (disclaimer, I'm one of the Epic devs and I designed all of them during the last 5 years of DDD trial and errors).