В каких случаях стоит прибегать к использованию архитектурных подходов?

Кратко: в каких случаях можно обойтись без разбиения приложения на слои и следования Clean Architecture, DDD и т.д., а в каких лучше делать все по правилам?

Допустим, есть задача разработать REST API. В приложении будет 12 сущностей. Сложных бизнес правил нет. В основном нужны только CRUD операции. Иногда, перед выполнением какой-нибудь операции нужно проверять права доступа пользователя к конкретному объекту (например, комментарию). Стоит ли разбивать приложения на слои, следовать Clean Architecture или DDD и т.д? Или же запихнуть весь код в один проект, с использованием Entity Framework работать с БД, маппить сущности EF на модели ресурсов API, и возвращать их пользователю? Вся логика при этом будет находиться в контроллерах.
  • Вопрос задан
  • 105 просмотров
Пригласить эксперта
Ответы на вопрос 2
angrySCV
@angrySCV
machine learning, programming, startuping
Уверен в начале нужно делать максимально просто, максимально примитивно и только ПОСТЕПЕННО развивать продукт, и только ТАМ где это надо.
Ни в коем случае нельзя заниматься оверинженерингом, возможно на следующей итерации вообще половина функционала будет выкинута и в совсем другом направлении будете развиваться, а даже если не выкинута, то будете пересматривать саму модель данных, схемы взаимодействия и тд.
Такие вещи должны постепенно рождаться отвечая вашим потребностям. Не нужно внедрять подходы или технологии (какие-то слои) только для того чтобы внедрить. Нужно точно отвечать на вопрос ЗАЧЕМ, и ПОЧЕМУ вы это внедряете, пока нет на эти вопросы ответа, значит такой подход или технология не нужна.
Соответственно если вы спрашиваете надо ли вам это делать -> ответ однозначно нет. Пока вы сами не дорастете до понимания где и зачем это надо делать.
Ответ написан
@922j
Разбитие облегчает дальнейшую модернизацию (поддержку).

Если вы сразу мысленно видите проект сразу целиком со всеми деталями и вам известно что именно в таком виде он будет всегда - можете не разбивать.

Если вы хотите сэкономить на разработке сейчас, если вы не хотите напрягать мозг сейчас, а что будет с проектом потом вам наплевать - можете не разбивать.

Если вы не хотите тестировать автоматически, частями. Если вы настолько самоуверены или считаете что поверхностных тестов будет достаточно - можете не разбивать.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы