WCF domain-specific contract, service and DTO separation -

we have multiple wcf services different domains/scopes (application-specific data, users, management etc.). automap entities dtos, here encounter first design issues.

how could, , should, separate services, contracts , dtos?

this tricky if need different views on same data - i.e. user might able read data himself, should not associated management-data since outside of scope.

my initial approach have been put dtos , contracts separate assembly each domain, or rather each service (e.g. corecontracts, ordercontracts etc.). makes separation of different views on same data harder, if don't want add new services serve data these views.

example (omitting attributes):

public class userdto {   public int userid {get; set;}   public string username {get; set;}   public string email {get; set}   public string address {get; set;}   public bool examplemanagementflag {get; set;} } 

this example , not how implemented

the examplemanagementflag user, himself or services on behalf of user, should not see. therefore use separate dto user-side access, plus separate contract , place in separate namespace/folder in corresponding contracts assembly.

but: using separate contracts make maintaining wcf bindings nightmare (multiple services, multiple environments configure - i.e. each developer has debugging-environment, have test-deployment environment , production-deployment environment...) - on other hand, putting 1 large contract yield ugly methods getuser(id) , getuserforuser(id) etc.

...another option, not prefer (which project uses...) create separate contract each client-server relationship. stuff orderwebservice.orderwcfservice, orderwcfservice.corewcfservice, corewebservice.corewcfservice - , let's not forget corewcfservice.orderwcfservice...

authorization not issue if have separate methods , dtos. i'd avoid returning same dto requests because doesn't tell fields applicable context - , pollute business logic authorization instead of relying on resource based authorization (i.e. user read on userscope.user, not read on superset.user - or readforuser on user not readall).

i hope i've written makes sense or helps explain problem i'm facing. i'm struggling put comprehensive words.

edit current pattern use in project has lead literally copied dtos on place, argument might need diverge some day