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

Question

[Финн Парнишка]

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

Допустим, есть задача разработать REST API. В приложении будет 12 сущностей. Сложных бизнес правил нет. В основном нужны только CRUD операции. Иногда, перед выполнением какой-нибудь операции нужно проверять права доступа пользователя к конкретному объекту (например, комментарию). Стоит ли разбивать приложения на слои, следовать Clean Architecture или DDD и т.д? Или же запихнуть весь код в один проект, с использованием Entity Framework работать с БД, маппить сущности EF на модели ресурсов API, и возвращать их пользователю? Вся логика при этом будет находиться в контроллерах.

Comments

[Максим Федоров]

Стоит ли разбивать приложения на слои, следовать Clean Architecture или DDD и т.д?
Или же... Вся логика при этом будет находиться в контроллерах.

Можно и без крайностей
Набросать проект, но логику вынести в сервисы, тк почти сразу некоторые методы и куски кода нужно использовать в нескольких местах даже в простом CRUD
Но упарываться в DDD конечно стоит тогда, когда вы знаете зачем, если есть вопрос -- вы этого не знаете точно :)

Answer 1

[⚡ Kotobotov ⚡]

Уверен в начале нужно делать максимально просто, максимально примитивно и только ПОСТЕПЕННО развивать продукт, и только ТАМ где это надо.
Ни в коем случае нельзя заниматься оверинженерингом, возможно на следующей итерации вообще половина функционала будет выкинута и в совсем другом направлении будете развиваться, а даже если не выкинута, то будете пересматривать саму модель данных, схемы взаимодействия и тд.
Такие вещи должны постепенно рождаться отвечая вашим потребностям. Не нужно внедрять подходы или технологии (какие-то слои) только для того чтобы внедрить. Нужно точно отвечать на вопрос ЗАЧЕМ, и ПОЧЕМУ вы это внедряете, пока нет на эти вопросы ответа, значит такой подход или технология не нужна.
Соответственно если вы спрашиваете надо ли вам это делать -> ответ однозначно нет. Пока вы сами не дорастете до понимания где и зачем это надо делать.

Answer 2

[922j]

Разбитие облегчает дальнейшую модернизацию (поддержку).

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

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

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

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