MVV

Абстрактно "правильного" варианта реализации нет, всё зависит от конкретных деталей.
В частности, посмотрите, используют ли ваши методы действий одни и те же внешние зависимости, или каждый - свои. Во втором случае некотоый смысл разнести их по разным контролерам есть: снизить сложность, которую дают лишние, не обусловленые задачей связи (coupling). А первом случае - нет (но может и появиться по другим основаниям).

А вся эта теория "чистой архитектуры" - она абстрактная. Ее полезно знать, чтобы иметь возможность рассмотреть больше вариантов решения, и видеть больше про возможных подводных камней, а вот фанатично ей следовать не стоит (если, конечно, ваша задача - сделать что-то полезное, а не спихнуть курсовик и т.п.).

Причина ошибки, как пишется в сообщении о ней - переполнение стека. Размер стека для потогков определяется процессом, в котором работает приложение. Обычно он фиксирован и записан в заголовке .exe. Если при размещении веб-приложения в своем процессе (так делается запуск из Visual Studio) стека хватает, то настройте размещение приложения вне процесса и в IIS: документация - здесь, по умолчанию AFAIK для IIS используется размещение приложения ASP.NET Core внутри его рабочего процесса, и используется размер стека этого рабочего процесса.

PS А вообще, я бы на вашем месте пересмотрел код миграций и использовал стек (локальные переменные методов имеющие тип значений, память, отводимая через stackalloc и т.п.) в нем по минимуму. Потому как требования к памяти приложения имеют свойство расти со временем, а стек задается фиксированной величиной.

Привыкли к миксинам в языке с динамической типизацией? В C# их нет, и вряд ли будут, потому что типизация тут статическая. И приемы программирования - соответственно, другие.

В частности, чтобы добавить дополнительное свойство (или метод) в классы из разных иерархий наследования, используйте интерфейс. Примерно так (примеры - на основе кода из комментариев):

public interface IChosable {
    bool IsChosen {get; set;}  //Желательно имена писать таки на английском правильном
                                             // а не ломаном. А то глаза режет.
                                             //Ну, или хотя бы - по русски транслитом: 
                                             // Vybrano вместо IsChoised - и то лучше, IMHO
}

//...
    public class ViewedDirectoryData : DirectoryDataEntity, IChosable
    {
        public bool IsChosen {get; set;}  
    }

    public class ViewedOutputData : OutputData, IChosable
    {
        public bool IsChosen {get; set;}  
    }

Но свойства, таки да, придется определять в каждом классе, реализующем интерфейс (но можно перенести их, вместе с указанием реализации интерфейса, в базовые классы иерархий).

Удобство тут в том, что ссылку на любой из классов, реализующих интерфейс, можно привести к типу интерфейса - тогда и статический контроль типов сохраните, и работать со всем этими классами можно будет единообразно.

Вы неправильно понимаете класс enum. enum - это не класс, а ключевое слово языка C#.

PS

И я задумался:

Надо не думать, и даже - не знать. Надо - уметь применять. Подумайте, какую практическую задачу вы хотели решить этой задумкой? Если такой задачи нет - не забивайте себе голову. А если желаете забить себе голову чисто для себя чем-нибудь абстрактным, то для этого лучше всего подойдет философия, а не IT.

Есть подозрение, что при каждом вызове тестового метода с новым параметром экземпляр вашего тестового класса каждый раз создается заново, вместе с новым экземпляром имитатора (Mock> _ratingRecordRepositoryMock; ) . В пользу этого говорит и то, что вы при каждом вызове заново настраиваете имитатор заново, а если бы экземпляр имитатора уже использовался, вы бы получили ошибку.

Проверить просто: поставьте точку остановки (или воткните отладочное сообщение) в конструктор тестового класса.

Зависит от того, чего вы хотите.
Если вас устраивает, что задача, выполняющая HandleClientAsync для подключившегося клиента будет брошена на произвол судьбы, можно использовать оба варианта (но первый мне нравится больше). Если вы хотите узнать, чем она закончилась - надо делать по-друому.
PS См. также комментарии к вопросу.

Есть несколько соображений.
Сображение первое, глубоко теоретическое. Логическая структура конкретного приложения - это вопрос специфичный именно для приложения. Думать о ней в терминах соответствия некой теоретической "архитектуре" (тем более - "чистой архитектуре") - это самоограничение, достойное только зеленых новичков. Настоящие программисты не используют чистую архитектуру. Кароче, как вы приложение напишете, такая у него архитектура и будет. Возможно, если ваше приложение будет в чем-то замечательным, то эта архитектура войдет в учебники по этой самой архитектуре, в качестве примера (может - положительного, но, скорее, отрицательного ;-) ). Но пока что вам нужно решать практические вопросы, и шаблоны т.н. "архитектуры" могут служить только в качестве подсказки, а решать придется вам, из чисто практических соображений.

Соображение второе, практическое. Раз, как вы пишете "Domain содержит только сущности, Enum'ы", то выбросьте из головы слово Domain, оно вас только запутывает. Потому что намекает на DDD, а то, что у вас есть, в DDD обзывают "анемичной моделью", и сильно не любят. Т.е. сейчас, с нынешней структурой приложения, DDD - оно не про вас.

Так что, по факту, у вас есть два слоя абстракций, описывающих функции классов и методов: UI и Application. И я подозреваю, что логика приложения - классы и методы, отнесенные к Application - использует в качестве средства доступа к БД EF напрямую. То есть - что там прямо в коде используются сущности под названием DbContext и DbSet.

А это означает, если по жизни, что от EF вы в таком раскладе никуда впоследствии не денетесь. Хорошо это или плохо - решать вам. Однако о намерении прибить гвоздями свое приложение к EF вы не упоминали и, предполагаю, не думали. Если это так, то задумайтесь именно об этом. Не о замене БД - EF может работать поверх разных БД, так что к MS SQL вы, по факту, с EF привязаны не будете (ну, разве что, сами того очень захотите).

А задуматься надо: EF - штука неоднозначная. Она, подобно любому средству ORM, полна абстракций, которые, так скажем, не совсем хорошо ложатся на логическую структуру реляционных БД, а потому в них есть заметные дыры, через которые эта структура будет проглядывать. В частности, это нередко касается вопросов производительности.

Но если вы выберети жизнь EF и ни с чем другим, то о Repository и UoW можете больше не думать: EF будет для вас и тем, и другим.

Кароче, выбирайте.

Добавьте в начало файла строку using System.Linq;
чтобы указать компилятору искать методы расшерения в этом пространстве имен.
ToList() - это метод расширения для интерфейса IEnumerable<Matches>, который реализуется объектом, который возвращает метод Regex.Matches. Этот метод определен (как обобщеный, для IEnumerable<T>) в классе Enumerable из пространства имен System.Linq.
PS Подозреваю, что у автора примера ссылка на это пространство имен живет в Global Usings, а потому у него все работает, а у вас - нет.

Task (задача) - это не Thread. Это спрецифичный для исполняющей системы (CLR) .NET объект, который позволяет отследить завершение выполнения операции, выполняющейся независимо от вашего основного потока управления и получить результат выполнения, если он есть (в вышем случае результата нет). Для запуска задачи, которую возвращает асинхронный метод (в отличие от вновь созданного объекта задачи - new Task(...)) ничего делать не нужно - она уже запущена исполняющей системой. Поток (Thread) для ее выполнения, если он нужен (а нужен он не всегда, иногда задача завершается внутри асинхронного метода синхронно) обычно берется из пула потоков (но могут быть нюансы, если они вам интересны - читайте про SynchronizationContext).
Если вам нужно дождаться выполнения задачи в синхроннном коде (у вас сейчас такой), то следует использовать метод задачи Wait(), но он заблокирует основной поток. Альтернатива для современного .NET (7.3 для этого достаточно современный) - использовать асинхронный метод Main: просто указать static async Task Main() вместо static void Main. Тогда можно дожидаться выполнения Install асинхронно, с помощью операции await: await update.Install(); При этом основной поток блокироваться не будет, но если ему все равно делать нечего (это зависит от типа приложения), то выигрыша от этого не будет (в консольном приложении, например).
PS Зачем вы применили атрибут [STAThread] к метод Install? Ведь, согласно документации

Примените этот атрибут к методу точки входа (Main()метод в C# и Visual Basic). Это не влияет на другие методы

То есть, он тут бессмысленнен. И вообще, это - тяжкое наследие технологии OLE2/COM.