c# - What Should a domain Model return when using an interface? -

i have got mvc application in domain model (data model + business model) resides in different class library. using interface exposing methods must return data not entire representation of domain objects.

my question how should return data?
should create kind of view models on business model layer , match them real view models on main application (views-controllers-viewmodels)?
should return data dynamic objects?
should return entire domain object event need couple of properties only?
best approach follow?

this example give better idea situation:

//domain class public class user {    public string username { get; set; }    public int userid { get; set; }    public string userpassword{ get; set; }    public string firstname{ get; set; }      public virtual icollection<applicationuserteam> applicationuserteams     {         { return _applicationuserteams; }         set { _applicationuserteams = value; }     }       }   public interface itrackattendance {   dynamic getuserscompany(int companyid);  }   public class trackattendanceservices : itrackattendance {     //method returning dynamic object???     public dynamic getuserscompany(int companyid)     {          using (var _ctx = new trackattendancedb())         {             return _ctx.users.where(u => u.applicationuserteams.firstordefault().team.companyid== companyid)                                     .select(u =>                          new                           {                             username = u.username,                             userid = u.id,                             userstate = false                           }).tolist();           }      }  } 

project architecture:

my solution:

thanks experts have given opinion question, have decided follow dto approach (@uk2k05) base on following aspects:

• it allows me keep clean architecture.
• this approach more in line single responsibility principle
• it ensures application layer isn't dependent upon underlying domain model.

i have acknowledge other interesting approaches raised here, such factory pattern(@liam) , command-query separation (cqs)(@l-four), both of them useful deal problem add complexity , work specific environment. cqs , fp require mind shift defining architecture (from humble , personal opinion).

have @ command-query separation (cqs). means split query side command side.

for commands, updating of creation of entities, go through domain model doing now.

however, queries, there no need go through domain layer not altering system in way, retrieving information. therefore, can bypass domain layer, query database directly , return (projected) data entities; in controllers mapped dedicated view models , passed views. projected, mean don't expose data layer directly, dto's constructed based on it; different domain model entities.

lots of information found it, example read here.