Привет,
Словосочетание "правильная разработка" порождает лишь неразбериху.
К примеру, ты делаешь какой-то компонент на фронте, на бекенде довольно стандартный CRUD. Но ты можешь сделать один метод Edit, а можешь сделать два метода Create и Update. И то и то правильно в зависимости от ситуации. Дальше, к примеру в методе Create у тебя проставляются пользователь, создавший запись и какое-то ещё поле, которое заполняется на бекенде. При этом, можно использовать одну и ту же модель во всех методах, Details/Create/List/Update. При этом, в метод Create попадёт модель с лишними полями, тот же пользователь, создавший запись. Кто-то скажет, это неправильно, нужно под все методы делать свои модели, если поля не используются, не должно быть возможности их передать. А кто-то скажет, неправильно плодить лишние сущности, пусть поле не используется, оно всё равно на бекенде перезаписывается. А кто-то скажет, что вообще не нужна даже одна промежуточная сущность, можно использовать сущность, которая генерится каким-нибудь инструментом с БД, так как проект представляет собой закрытую админку для внутреннего пользования.
Немного сумбурно, но, надеюсь, понятно.
Дальше идёт расхождение в инструментах, к примеру, требуется делать валидацию входящей модели. Можно использовать Fluent валидацию или использовать декларативный синтаксис через Data Annotation. И то правильно и это правильно, в одном проекте, разумеется, должно использоваться что-то одно, но подход и синтаксис различаются очень сильно. Или так же, необходимо использовать IoC/DI, а инструментов под это несколько и все правильные.
Что касается архитектуры. Опять же, есть несколько подходов и несколько стилей. Нельзя сказать, что один из них правильный, а другой неправильный. Я видел несколько отвратительных проектов, написанных в ООП стиле. При этом, не могу сказать. что подход неправильный и нет хороших проектов, написанных по такому принципу. Я видел огромный проект, отлично написанный в процедурном стиле со слоёной архитектурой контроллер/модель/интерфейс/сервис/энтити. Даже представить себе не могу, если бы его попытались сделать в Domain Driven Design или в компонентном стиле, типа микросервисов.
В общем, нет в этом деле серебряной пули.
Что касается основных "правильных" вещей. Есть спецификации языка и им надо следовать. Если взять, к примеру, ангуляр. То в нём есть свои стандарты, есть сайт с документацией, в которой прописаны правила наименований и прочее. Им надо следовать. Если взять .net, то при выходе новой версии, вместе с ней выходит и спецификация на новые фишки. Так же, в нормальных проектах ведётся свой файл со спецификацией, в котором указаны, в каком порядке следует размещать публичные/приватные поля, что один публичный класс должен быть в отдельном файле и имя файла должно совпадать с именем класса. Так же, при выходе новой версии IDE, под .net это visual studio, внутрь уже встраиваются подсказки, например, если ты написал класс с маленькой буквы, студия это подчеркнёт и укажет, что наименование класса должно быть в PascalCase. В общем, этому надо следовать. Могу скинуть свои файлы на почту.
Могу так же скинуть свой проект на гитхабе, но, как я уже говорил, не факт, что архитектура из того проекта подойдёт, когда вы придёте в другую разработку, там архитектор скажет "это неправильно, мы не так делаем"
