This is just for personal learning, not related to a real application.Let's say I have the following project structure:DB.ClientDB.CoreDB.DataAccessClient is well, obviously a client project, Core contains all interfaces related to business, and DataAccess has database models and it also implements repository interfaces that are defined in the Core project. The repository would be the only thing that really talks with the actual database, and it would map database objects to business objects.Db.Core has, for example a definition for a User:public interface IUser{    string FullName { get; }}It also has it implementation, Userpublic class User : IUser{    public User(string FirstName, string LastName)    {        FullName = FirstName +   + LastName;    }    public string FullName { get; }}I'm not really sure about the terminology, but I assume I can call these my business objects.Now in the DB.DataAccess, I have the following class (model):public class UserDBO{    public int Id { get; set; }    public string FirstName { get; set; }    public string LastName { get; set; }    public int Age { get; set; }    public List<UserItemDBO> UserItems { get; set; }}and the following repository:public class UserRepository : IUserRepository{    public IUser FetchUser()    {        var user = new UserDBO        {            FirstName = cool,            LastName = name        };        return new User(user.FirstName, user.LastName);    }}Is this a correct way to think about project structure? This way, my client projects would never need to know about the actual database models, and only care about the business related objects (IUser). The mapping from database model to business model would be done by the repository, so clients using the repositories would only get returned real business objects.Please let me know if this somewhat good design, and if it's not could you guide me to a better way of thinking this.
Organizing Database and Business Objects in project
c#;design;architecture;project structure