я думаю, что могу найти в любом коде нарушение single responsibility. SOLID это инструмент. А исходить нужно из вашего ТЗ, а не из страха что Дядюшка Боб заругает.
Пример когда локализация на бэке логичнее: у вас много клиентов апи, некоторые писали не вы, но на всех клиентах вы хотите сохранить одинаковость текстов.
Пример когда локализация на фронте логичнее: у вас один клиент и вообще вы больше шарите во фронте и лишний раз не хотите в бэк лезть.
FairyFox5700, запросы к redis будут дольше потому что у вас будет сетевое взаимодействие. Просто взять из памяти само собой быстрее.
К типу проекта не привязан.
Пока у вас не будет твердой уверености что в вашей системе нужен Redis и не будет ответа на вопрос «зачем и почему именно он?», рекомендую не добавлять его в проект. Потому что это дополнительная точка отказа и дополнительная сложность.
FairyFox5700, зависит от того, что вы в нём собрались хранить. Если этим пользуется только это приложение и потеря кэша при перезагрузке/перепубликации приложения вас не пугает, то можно использовать просто стандартный MemoryCache
Иван Шумов, да я понимаю) просто форма постановки вопроса заставила меня предположить что возможен оверхед в виде редиса. И, возможно, вопрос можно решить, не используя редис. Или нет)
Dmitry, я не очень понимаю почему у вас 2 отдельные сущности user и аккаунт. Как пользователь входит в мероприятие если он не зарегистрирован? Как происходит аутентификация?
Dmitry, ввести роль Руководитель назначить эту роль для аккаунтов руководителей. Ввести роль Участник. Преобразовать участников в аккаунты с использованием с сохранением Id участника. Назначить роли для участников. Научить приложение работать с ролями.
Dmitry, что-то вы усложняете. Делайте регистрацию пользователя с определенной ролью. В зависимости от роли открывайте функционал (создание других, личный кабинет итд). Не должен новый функционал менять идентификатор пользователя.
ftl87, правильного выбора не будет хотя бы потому что сфера эволюционирует, появляются новые языки и подходы. Если у вас хорошие отношения с вашими «советчиками» то берите питон, будет с кем обсудить — это ускорит ваше развитие. Я бы рекомендовал отойти от формирования в голове «идеального» плана — это сковывает. И перейти к идее наилучшего использования текущих обстоятельств.
FairyFox5700, а как вы собираетесь этого избежать если в DI контейнере всё равно будете регистрировать все эти типы? Смысл же в том чтобы нижние уровни не знали о верхних, т.к. это помогает их переиспользовать и заменить в случае чего. Корень композиции в любом случае будет знать обо всех типах в дереве ссылок, по определению
