Привет! Грубо говоря, интерфейс лишь описывает функциональность. А класс, который реализует этот интерфейс, должен конкретно функциональность определить. Например:

interface IVegetable {
    name: string;
    getCalories(): number;
}

А конкретный класс:

class Tomato implements IVegetable {
    name: string = 'Tomato';
    getCalories() {
       return 18;
    }
}

Type - это лишь типизация какой-то переменной, как правило, нестандартной, Например, мы хотим определить тип, который будет описывать степень готовности стейков:
type SteakRoast = 'medium' | 'rare' | 'welldone';
Таким образом, мы можем присвоить переменной типа SteakRoast только эти предопределённые значения, а иначе Typescript заорёт из-за несоответствия типа.

Привет! Многое зависит от деталей и количества абстракций. Попытаюсь ответить как это должно выглядеть в самом общем случае. UserRepository использует напрямую доступ к базе данных (это может быть raw sql, какая-то ORM, неважно). Поэтому логично, чтобы он находился в Data Access Layer. Он поэтому так и называется, потому что на практике их может быть несколько: SqlDataAccessLayer, MongoDbDataAccessLayer и т.д. Также если мы говорим про ООП, то интерфейс IUserRepository должен хранится именно там, где планируется его использование. В нашем случае это BLL, он же Domain Layer. Не всегда удаётся придерживаться этого правила с интерфейсом, но к этому нужно стремиться.
По поводу того, что должен возвращать UserRepository: на самом деле без разницы. Смотря от ситуации мы можем либо возвращать просто контейнер c необходимыми данными (DTO), либо полноценного User'a. Если говорить о зависимостях, то главное понимать, что в общем случае наш Domain Layer не должен иметь зависимостей от каких-то других слоёв. А вот остальные части нашего проекта (например, DAL) могут использовать Domain Layer.

Привет! Хочу поделиться несколькими фишками, которыми сам пользуюсь постоянно. Во-первых, читать надо не на скорость и объем, а на понимание, читайте по часу в день, но вдумчиво. Во-вторых, перед началом изучения чего-либо обязательно ознакомьтесь с содержанием. Таким образом, читая определенную главу у Вас уже в фоне будет понимание того, что в конце этой главы Вы должны усвоить и как эта глава связана с контекстом всей книги. В-третьих, после каждого чтения или же после поступления новых знаний - вкратце записывайте их своими словами, чтобы через неделю, год Вы смогли взглянуть и освежить память. Много писать не надо, чисто тезисно.
P.S. Если есть время, то советую посмотреть курс на английском или прочитать книгу на русском от того же автора.

Поскольку мы в разделе ASP.NET, то буду говорить про него. Не знаю каким образом мы можем синхронизировать валидацию на фронтенде и бекенде, мне даже кажется это технически нереализуемо, но могу ошибаться. Если мы говорим о валидации в целом, то мы в первую очередь должны обеспечивать 100% валидацию на стороне сервера, потому что не хотим, чтобы была нарушена целостность данных и т.д. Тут надо руководствоваться принципом fail fast - как можно быстрее проверяем валидность данных из запроса. Чтобы привести валидацию к какому-то организованному виду можно использовать, например, библиотеку FluentValidation.

Сокрытие информации очень часто называют инкапсуляцией, но это не совсем корректно. Сокрытие информации - это своего рода ограничение доступа к таким полям/методам/т.д., которые можно менять только внутри модуля. Типичный пример: объявление private переменных.
Инкапсуляция - это сокрытие деталей реализации. Мне нравится следующий пример инкапсуляции из реальной жизни. У нас есть объект - наручные часы, этот объект реализует интерфейс IGetTime. Мы просто смотрим на часы и получаем время. При этом нам совсем не интересно каким образом это время было рассчитано внутри часов, какие инструменты при этом использовались, механические часы или цифровые - это всё не важно. Важно, что мы узнали время, а всё остальное - детали реализации, которые скрыты от нас. Аналогично и в ООП.
Таким образом, сокрытие информации является лишь частью инкапсуляции.