Q:

Application architecture for client to WCF service

I'm curious about the correct way to architect an application that consists of the following (that needs refactoring):
Excel Addin
COM-Visible client library that includes WinForms and Methods exposed to Excel (calculation calls and form activation methods)
This then uses functionality in the client library to connect to the WCF services.
WCF services currently contain calculation logic, validation logic, database access via ORM tool.
i.e. Addin -> Winform/Direct call in client DLL -> WCF -> DB or calculation
Currently this exists in just 2 projects. My first though would be to re-architect as follows:
Client Side Projects

Excel "View" (Project.Client.Excel), this limits the level of COM visibility to one project.
WinForm "view" (Project.Client.UI)
Presentation for both sets of "views" (Project.Client.Presenter)

Server Side Projects

WCF "view" including data transfer objects? (Project.Server.WCF or Service)
Server side presenter (Project.Server.Presenter)?
Business Logic (Project.Business)
Data Access Layer (Project.DAL)

My questions are:

Where should the DTOs sit, in the WCF project or as their own library/project?
Where do the entity conversion routines belong (Data entity <> Business Entity <> DTO)? All in the business logic layer or some there and some in a server presenter?
What should the correct architecture be for this type of scheme?
Plenty else I've probably missed?

Part of the idea for the refactoring is to correct the architecture, separate concerns etc, and enable the inclusion of unit tests into the design.

A:

This is how I would structure that but there is no 100% correct answer to this question. Many variations will make sense until they make your work comfortable.

Excel "View" (Project.Client.Excel), this limits the level of COM visibility to one project.
WinForm "view" (Project.Client.UI)
Presentation for both sets of "views" (Project.Presenter)
WCF Host (Project.Service) - Web Site with *.svc files if you host in IIS (no contracts here). No much business code here it is only for hosting methods implemented in BLL. 
Business Logic (Project.Business)
Data Access Layer (Project.DAL)
Contracts (Project.Contract) - Operation and Data Contracts. This is library used by both WCF client, server and BLL.
Shared (Project.Shared) - common helpers to better structure dependencies. 

Where should the DTOs sit, in the WCF project or as their own
  library/project?

Contracts

Where do the entity conversion routines belong (Data entity <>
  Business Entity <> DTO)?  All in the business logic layer or some there and some in a server presenter?

Business for middle/small size project. 

What should the correct architecture be for this type of scheme?

Your seems to be fine.
Server side presenter (Project.Server.Presenter) - this makes no sense for me because there is no GUI that consumes it

