AlexHell

проектирование (не только десктопы)
* Тепляков С. - Паттерны проектирования на платформе .NET - 2015
* Нильсон - DDD - 2008

UI
* чтото по Win Forms \ WPF (хотя мои знания по ним несколько устарели)
* Алан Купер об интерфейсе. Основы проектирования взаимодействия - 2009

если делать игры / визуализацию (не просто формочки) - кроссплатформ сейчас на unity (билд и под ПК и под мобилы и под webgl)

class User {Id, Name, Age}

class UserRepository
{
 User GetUserById(long Id)
  {
  string[] data = {select from Users where id = Id}
  return new User() {Id = Id, Name = data[0], Age = data[1] };
  }

  void PutUser(User)
  {
    {insert into Users}
  }
}

Зачем вам UserEntity? Если у вас доменный объект User - везде его и передавайте, и Repo олжен его же вертать при чтении из БД и его же принимать чтоб сохранять в БД.

Если вопрос в EntityFramework (и иже с ними ORM) с обязательным отнаследованием от базового Entity класса - ну сделайте маппинг опять же внутри UserRepo и не отдавайте вообще никогда вовне UserEntity, всмысле как private class например чисто для namespace / пакета

Юзайте SQL базу с которой знакомы, т.е можете конфиг настроить, подтюнить, производительность замерьте и все будет быстро. На счет NoSQL - вообще сомнительная наработка как по мне, все можно в SQL, с prepared statement если на парсинг SQL времени много (только по рез-там тестов).

Я сам не реализовывал микросервисы, но недавно на хабре читал про JSON Web Token да вот на википедии даж https://ru.wikipedia.org/wiki/JSON_Web_Token
и вот еще про Access + Refresh Token https://habrahabr.ru/company/Voximplant/blog/323160/
смысл в том есть служба аутентификации и выдачи токена, она своим секретным ключем шифрует токены (1 access или 2 access + refresh) и выдает клиенту, в простом случае я бы записал туда ID юзера и его Роль (админ, обычный юзер), и передавал с клиента на каждый микросервис, который его проверяет:
-- в 1м из вариантов расшифровывает секретным ключем - тогда каждый микросервис знает о секрет ключе основном которым подписывал сервис аутентификации
-- во 2м варианте юзаем ассимметричное шифрование т.е секрет знает толькосервис аутентификации а другие его беспроблемно расшифруют (меньше подвергаемся утечке ключа если много сервисов и не всем мы доверяем)

во всех случаях сервис к которому обращается клиент не должен обращаться к сервису аутентификации что не замедляет скорость работы.