ASP.NET Core по стандарту предлагает настраивать доступ к api с помощью атрибутов, есть возможность ограничить доступ пользователям с определенным claim, можно определять политики и привязывать к контроллерам, создавая контроллеры для разных ролей
У этой системы есть минусы, самый большой в том, что смотря на этот атрибут:

[Authorize(Roles = "Administrator")]
public class AdministrationController : Controller
{
}

Мы не получаем никакой информации о том, какими правами обладает администратор.

Кому-то не нравился Redux в React из-за его имплементации на JS?

Мне он не нравился корявыми switch-case в reducer'ах, есть языки с более удобным pattern matching, и типы лучше моделирующие события и модель. Например, F#.
Эта статья — разъяснение устройства обмена сообщениями в Elmish.

Specifics of QueryProvider

QueryProvider can’t deal with this:

var result = _context.Humans
                      .Select(x => $"Name: {x.Name}  Age: {x.Age}")
                      .Where(x => x != "")
                      .ToList();

It can’t deal with any sentence using an interpolated string, but it’ll easily deal with this:

var result = _context.Humans
                      .Select(x => "Name " +  x.Name + " Age " + x.Age)
                      .Where(x => x != "")
                      .ToList();

The most painful thing is to fix bugs after turning on ClientEvaluation (exception for client-side calculation), since all Automapper profiles should be strictly analyzed for interpolation. Let’s find out what’s what and propose our solution to the problem.

То, о чем написано в статье, я отлавливал около 10 часов, это были 10 часов непрерывного дебага, которые cвелись к пошаговому сравнению рабочей и нерабочей версий кода, даже не так, к сравнению каждой строчки из окошка дебага рабочей и не рабочей версий кода

Парадигма CQRS в том или ином виде предполагает, что вызовы Query не будут менять состояние приложения. То есть многократные вызовы одной и той же query, в рамках одного запроса, будут иметь один и тот же результат.

Пусть все интерфейсы, использующиеся в рамках запроса будут иметь тип IQuery или IAsyncQuery:

public interface IQuery<TIn, TOut>
{
   TOut Query(TIn input);
}

public interface IAsyncQuery<TIn, TOut>: IQuery<TIn, Task<TOut>
{
}

AutoMapper один из основных инструментов применяемых в разработке Enterprise приложений, поэтому хочется писать как можно меньше кода определяя маппинг сущностей.

Мне не нравится дублирование в MapFrom при широких проекциях.

CreateMap<Pupil, PupilDto>()
 .ForMember(x => x.Name, s => s.MapFrom(x => x.Identity.Passport.Name))
 .ForMember(x => x.Surname, s => s.MapFrom(x => x.Identity.Passport.Surname))
 .ForMember(x => x.Age, s => s.MapFrom(x => x.Identity.Passport.Age))
 .ForMember(x => x.Number, s => s.MapFrom(x => x.Identity.Passport.Number))

Я бы хотел переписать так:

CreateMap<Pupil, PupilDto>()
 .From(x=>x.IdentityCard.Passport).To()

Тонкости Queryable Provider

Queryable Provider не справляется вот с этим:

 var result = _context.Humans
                      .Select(x => $"Name: {x.Name}  Age: {x.Age}")
                      .Where(x => x != "")
                      .ToList();

Он не справится с любым выражением, которое будет использовать интерполированную строку, но без трудностей разберет такое:

 var result = _context.Humans
                      .Select(x => "Name " +  x.Name + " Age " + x.Age)
                      .Where(x => x != "")
                      .ToList();

Особенно болезненно править баги после включение ClientEvaluation(исключениe при вычислении на клиенте), все профайлы автомаппера должны быть подвергнуты жесткому анализу, на поиск этой самой интерполяции. Давайте разберемся в чем дело и предложим свое решение проблемы