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

1. Комменты не нужны, ведь разработчик и так может подсмотреть всю нужную информацию в IDE
2. Комменты опасны, ведь после рефакторинга можно забыть их проапдейтить - и тогда они будут хранить ложную информацию
3. Комменты замедляют девелопмент
4. Комменты уменьшают читабельность кода

Исходя из выше описанного, я предлагаю сделать комменты необязательными.

Технически, сейчас можно реализовать агрегаты бизнес-логики, даже на клиенте.
Замокать можно хранилище и event-store

Привет,
Наткнулся на твою статью на хабре, с неё перешёл на гитхаб.
Меня заинтересовал твой репозиторий. Я был бы не против помочь в его разработке.
Сейчас идёт hacktoberfest. Я могу помочь в рамках этого мероприятия.
Если есть работа для меня - заводи issues и описывай, что нужно сделать. Я буду делать по мере возможности.

Сейчас все команды имеют одновременно:

1. Свойства, которые описывают структуру команды
2. Метод ApplyOn, который хранит в себе логику обработки команды (почти всегда там просто вызов репозитория)

Я вижу в этом следующие проблемы:

1. Нарушение SRP.
2. Проблемы с расширяемостью. Когда для обработки команды нужно будет больше кода, чем вызов репозитория, то непонятно, куда этот код ложить - в саму команду, в сервис выше или в репозиторий.
3. Смешение парадигм - команда одновременно и ДТО, и объект. Выходит, тут одновременно и структурное програмирование, и ООП.

Я предлагаю сделать команды просто как ДТО, а логику их обработки выносить в отдельные хендлеры. При этом, репозитории могут принимать саму команду в своих методах, что освободит от лишнего перекладывания параметров.

Более того - такой подход можно использовать и для query запросов. Все get запросы тоже можно оформить как дто+обработчик. Тогда высокоуровневые сервисы (каталоги) будут создавать команду или запрос и передавать их в нужный хендлер. Чтобы уменьшить связанность, можно использовать MediatR. Он будет находить подходящий обработчик для команд и запросов автоматически.

Создать
установить пароль
установить роль

Сейчас при редактировании она перетирается. Надо ее восстанавливать

Сделать в бекенде - ?
Форнт в самом приложении - ?

В этот проект можно положить следующую логику:

1. Генерация Guid
2. Взаимодействие с внешними системами (IdenityServer4, SMTP server etc)
3. Интеграция разных библиотек - MediatR, FluentValidation etc
4. Взаимодействие с базой данных. Сейчас это лежит в DataAccess, можно этот проект трансформировать в Infrastructure.

Надо убрать все лишние boilerplate вьюхи и контроллеры. Оставить только окно авторизации.

CRUD контроллер

• хостинг статического сайта? DO?
• хостинг приложнния (та же машина, но другие порты? Отдельная машина? Oracle облако?)