Is it good to store CustomMembershipUser and Agregate classes in domain library

I need just a few confirmation that I do some stuff in the right way or I make horrible mistake :)

1) I put my data access layer (MyProject.Domain) in sepparate assembly. There I have entity object "User" that has properties in 1:1 relation with "User" table in my database. I also extend this user from "MembershipUser" because I use custom schema for membership. Is this good location to store MembershipUser entity?

2) I have "Image" table in database and "Image" entity in my domain library. Image in database has "AuthorId" column which is FK to "User" table. Also image contain list of "comments". So I structure Image domain object like this:

public class Domain
{
  开发者_运维技巧 public int ImageId{get;set;}
   public string Name{get;set;}
   public Author Author{get;set;}
   public IEnumerable<Comment> Comments{get;set;}
}

Is this good way or maybe I should assemble all data in a ViewModel class?

You should really make a distinction between domain models and view models. Domain models are those classes that represent your domain business entities. It could be EF autogenerated classes or whatever. So even being aggregate classes they are still domain models as they aggregate domain entities and could be stored alongside with other domain models.

View models are classes that are specifically defined for a given view. The view models are always defined inside the ASP.NET MVC project because they are tightly coupled to specific views which are themselves defined in the ASP.NET MVC project. Domain models could be defined in separate assembly. They are intended to be resused in other applications as well. Think of your domain models as the core of your business. If tomorrow ASP.NET MVC is no longer modern, and something else comes out you should still be able to reuse your domain models. The view models are only a specific representation of your domain models for some given and specific view.