Чистая архитектура решения, тесты без моков и как я к этому пришел

Это находится в сервисе, так как решается одним запросом.

Чистая архитектура решения, тесты без моков и как я к этому пришел

Пока что такая

Чистая архитектура решения, тесты без моков и как я к этому пришел

Первичтная валидация в основном атрибутами. Вторичная (если нужна, к примеру проверить что юзер есть) уже вызовом сервиса из метода контролера.

Чистая архитектура решения, тесты без моков и как я к этому пришел

Нет, такого не будет. В методе обновления проверяется версия файла (Дата изменения). Если она не совпадет, то изменения не будет, запрос выдаст ошибку. Почитайте код Update.
Это тестировалось в 50 потоков.

Чистая архитектура решения, тесты без моков и как я к этому пришел

А про тестирование всего кода я тоже написал, сейчас в разработке e2e тесты

Чистая архитектура решения, тесты без моков и как я к этому пришел

Я рассказал про решение параллелизма.
Проверка нужна в случае если id нет, очевидно же

Чистая архитектура решения, тесты без моков и как я к этому пришел

Стектрейс присылается в логи

Чистая архитектура решения, тесты без моков и как я к этому пришел

MakeToken() это метод на уровне апишки, это не Core, в этой задаче домен даже не будет изменен

Чистая архитектура решения, тесты без моков и как я к этому пришел

Обновил раздел Service, показал БД.
Весь проект не уверен что смогу показать, это не прототип, а реальное приложение.

Чистая архитектура решения, тесты без моков и как я к этому пришел

Нужно не забывать что код ещё и читают, а не только выполняют.
Я свою код могу править практически не запуская.

Чистая архитектура решения, тесты без моков и как я к этому пришел

В самой функции + 2 места использования, регистрация и вход.

Чистая архитектура решения, тесты без моков и как я к этому пришел

На счет инкапсуляции, согласен, нужно подумать как зыкрыть set и не потерять в удобстве Core

Чистая архитектура решения, тесты без моков и как я к этому пришел

Я рассказывал про код приложения где использовалась N-layer, это был проект который писало 7 разрабов.

А пока что ваши рассуждения выглядят как-то так: «Что за люди придумали экскаваторы? Сложно, куча абстракций, топливо залей, за рычаги подергай…

Я не говорил что абстракции — сложно, я говорю что их часто не оправдано много. А 4+ вложеностей абстакций с паарой реализаций, очень удобно дебажить, ведь так? Тыкаешь F12, оба посмотрел на список реализаций, ой, а теперь нужно понять какую из них заюзает runTime? а там, за выбор реализации по Id отвечает фабрика, с фаричным методом в придачу, и не забываем что у нас абстрактный репозиторий, с unit of work который обернул репозиторий EF (Db context). Время занимает просто понять как сработает код, не то чтобы ошибку искать. А че? зато заменяемо.

Чистая архитектура решения, тесты без моков и как я к этому пришел

… а не на уровне фронта у вас ошибок не бывает?

Обратите внимание что я возвращаю не только текст, а и код ошибки.
Текст нужен разрабу, код для справочника ошибок. Фронт по коду достает из словаря (eng ru) текст и дает внятный ответ ошибки

Чистая архитектура решения, тесты без моков и как я к этому пришел

1) Без миграции, в массиве у пользователя не будет новой currency — гарантированный exception
2) Выглядит грамоздко
3) Хотелось чтоб ошибки были собственного типа (AppError) для удобной обработки.

Чистая архитектура решения, тесты без моков и как я к этому пришел

Недавно была задача добавить ReferId в User, а дальше начилсять рефералу бонус после неких действтий. Задача решилась минут за 15. Добавил свойство в модель, расширил метод makeToken чтоб закинуть в JWT referId для быстрого доступа, в нужных местах достал id и по Id начилил бонус.

Глобальное кеширование результатов Query в ASP.NET CORE

Подход прикольный, но добавление чего-то нового призывает делать рутину, которую можно было избежать. К тому же сервисы имеют побочные эффекты, и нечего им делать в домене.
По моему мнению в домене должна лежать чистая логика, которую можно легко тестить, а заниматся моками для домена это как то странно.
Я стараюсь придерживаться такого принципа: домен — калькулятор.