Не правильный у вас какой-то сервер-сайд. В правильном сервер-сайде асинхронность > многопоточности. А ещё лучше, если сервер-сайд умеет и в одно, и в другое.
Советую его рассмотреть. Из всех спек oidc он не умеет только в динамическую регистрацию клиентов. По сути хост idsrv — это обычное mvc приложение, и если вы сможете аутентифицировать пользователя в этом приложении через какой-либо провайдер, то значит у вас +1 способ для логина. Только разбор советую начать с чтения спецификаций OAuth2.0 и oidc, а то можно долго путаться в его абстракциях, пытаясь изобразить требуемый результат))
Только OpenID Connect — это всё же протокол аутентификации (пользователей), который построен поверх OAuth 2.0, который уже, как раз, протокол авторизации (приложений). Как-то так)
Фабрики там служат сугубо для того, чтобы обернуть вызов IoC контейнера. Вопрос был в том — а нормально ли использовать его как основу для CQRS? API нравится, вроде даёт всё нужное. Правда интерфейс один — IRequest, но можно ведь сделать команды и запросы в разных сборках и следить за тем, чтобы обработчики запросов не изменяли состояния. Что скажете на этот счёт?
Дорого поддерживать DTO и SQL, так как схема может ощутимо так измениться в процессе рефакторинга. За этим и спросил по поводу «срезать углы» в этом моменте. А уже после, когда будет уверенность в том, что со схемой всё ок, и мы описали нашу предметную область на столько, на сколько это было возможным — уже «заплатить по счетам» и таки реализовать чтение полностью независимым от домена и EF, возможно переработав API и то, как данные возвращаются из API.
«Чистый» — это с полноценно раздельной записью и чтением, когда модификация состояния — это EF + DDD с транзакциями, а чтение — Dapper/ADO+DTO.
Я спросил, на счёт того — допустимо ли использование бизнесовых сущностей и контекста БД не только для модификации, но и для чтения на начальных этапах проектирования системы, так как домен там постоянно изменяется по мере уточнения требований. А так же спросил на счёт возможности использования готовой библиотеки в качестве инфраструктурной основы.
А если на начальном этапе разработки в качестве хранилища взять тот же EF Core, и оперировать его контекстом, как в командах, так и в запросах. А потом, по мере роста нагрузок и усложнения логики — проводить постепенный рефакторинг, устраняя узкие места (с использованием того же Dapper или вообще ADO).
Допустимо ли строить архитектуру таким образом?
Потому что строить чистый CQRS изначально, с отдельным представлением данных для CUD и R — довольно дорого, особенно в условиях, когда даже нет целостного представления о том какой должна быть модель (а это означает постоянный рефакторинг. Много рефакторинга).
И второй вопрос — что скажете на счёт MediatR в качестве инфраструктуры для CQRS. Там правда всего один интерфейс, но проблема деления на команды и запросы решается нэймингом.
Помимо mono для C# существует ещё и .net core — который, во-первых открытый, во-вторых кросс-платформенный. Если не затруднит — прогоните ваш бенчмарк и на нём.
Для авторизации есть OAuth 2.0.
Для аутентификации — OpenID Connect 1.0.
Зачем изобретать изобретённое?
В случае дотнета — есть IdentityServer, который реализует оба протокола.
Я спросил, на счёт того — допустимо ли использование бизнесовых сущностей и контекста БД не только для модификации, но и для чтения на начальных этапах проектирования системы, так как домен там постоянно изменяется по мере уточнения требований. А так же спросил на счёт возможности использования готовой библиотеки в качестве инфраструктурной основы.
Допустимо ли строить архитектуру таким образом?
Потому что строить чистый CQRS изначально, с отдельным представлением данных для CUD и R — довольно дорого, особенно в условиях, когда даже нет целостного представления о том какой должна быть модель (а это означает постоянный рефакторинг. Много рефакторинга).
И второй вопрос — что скажете на счёт MediatR в качестве инфраструктуры для CQRS. Там правда всего один интерфейс, но проблема деления на команды и запросы решается нэймингом.
Для аутентификации — OpenID Connect 1.0.
Зачем изобретать изобретённое?
В случае дотнета — есть IdentityServer, который реализует оба протокола.
И если не затруднит — то yield без батчинга.