Ciao.
Per come la vedo io, il service layer dovrebbe starsene rigorosamente fuori dal Business Layer.
Trovo quindi errato l'approccio per il quale il prodotto di una ws-request dovrebbe rappresentare il tuo "dominio", per una lunghissima serie di ragioni.
Il punto è che, come fai notare, dovrai costantemente garantire la sincronia tra le implementazioni dei proxy e quelli che lato WCF, ad esempio, vengono definiti "Service Contracts".
E non si scappa! :-)
Ti dico come faccio io.

Innanzitutto, cerco di disegnare il service layer in modo che le sue operazioni siano il più "fine-grained" possibile.
E poi, utilizzo i DTO.
Trovi qualche informazione al seguente link:
Data Transfer Object

In ultimo, da un pò di tempo mi avvalgo di quello che è stato definito un "Request/Response Service Layer".
E, siccome sono pigro, ricorro a questo strumento:
Agatha Request/Response Service Layer

Spero di esserti stato di aiuto.
E occhio ai domini anemici! ;-)

---

Modificato da naighes il 05 agosto 2011 08.38 -

Ciao.

Anche qui usiamo i dto che poi vengono trasformati in entity dagli script che replicano un interfaccia piú o meno standard con delle class extended per le eccezioni. Questo lo trovo terribile!

Sinceramente, non ho capito molto bene a cosa ti riferisci quando citi un'"interfaccia più o meno standard".
E' chiaro che non ho un quadro di quello che è il problema che ti trovi ad affrontare, ma io personalmente tendo a vedere un DTO come un qualcosa che deve essere "wrappato" all'interno di un messaggio.

Al seguente link è spiegato questo tipo di soluzione:
Patterns for Flexible WCF Services

Tutto questo, ovviamente, concerne il design del service layer.

Per quanto riguarda il mapping DTO/Entity e viceversa, puoi ricorrere ai Factory Method.
Ovviamente, non arriverai mai a scongiurare le problematiche derivanti dai breaking changes di cui sono affetti i DTO, ma limiterai l'impatto in termini di "modifiche da apportare al tuo Dominio".
Il mio consiglio è incapsula, incapsula e ancora incapsula!
Lavora per behavior e "nascondi" il più possibile lo stato della tua entity (ovvero, usa le proprietà il meno possibile).

Per quello che riguarda il mapping, prendi in considerazione "AutoMapper":
AutoMapper

Insomma, mettendo assieme tutte le risorse che ti ho indicato, per quella che è la mia esperienza arrivi a conseguire ottimi risultati in termini di riduzione dell'accoppiamento tra DTO e entità del dominio.

Fai qualche prova e magari parti proprio con qualche Unit Test.
In questo ambito, seguire una via "TDD" (seppur parzialmente) ti aiuta ad avere maggiore lungimiranza.

Ovviamente, IMHO.