1. Не всегда возможно распределить задачи так как хочется. Нам приходится сталкиваться с суровой действительностью, в которой Заказчик может диктовать собственные правила.
2. В Clean Architecture есть Use Case, который как раз отвечает только за одну фунцию. По крайней мере именно так я понял.
Все так. Тег выбран неправильно.
Этот «архитектурный» подход ближе всего к MVC с введением слоя Сервисов. Который в свою очередь вертикально разделяется на Query и Command.
Ну и фишка этого подхода в том, что Query или Command выполняет только одну задачу. Это позволяет не иметь конфликтов при разработке.
Собственно вся суть подхода описана в этом комменте.
Вот реально так? На примере абстрактного интернет-магазина: есть сущность «заказ», есть сущность «адрес доставки», есть сущность «строка заказа» (товар, количество) — и как минимум последняя не имеет никакого смысла вне первой. Зачем для неё отдельный контроллер?
Тут тоже наверное не вполне адекватно сформулировал.
Отдельный контроллер будет для сущности Заказ. И отдельный для сущности Товар.
Дальше дробить пожалй нет смысла.
Выбрать более узкую специализацию все же возможно.
Можно уйти в чистый фронтенд, а не пытаться быть фуллстеком. И во фронтенде выбрать конкретный фреймворк. Это сильно снижает скорость увеличения К2 в других областях. Правда может увеличить в конкретной области.
Но в конкретной области знаний К3 ограничен. То есть должно получится так K1 -> K2 -> K3. Но конечно же это всего лишь теория.
2. В Clean Architecture есть Use Case, который как раз отвечает только за одну фунцию. По крайней мере именно так я понял.
Сейчас конфликтов практически нет.
Все так. Тег выбран неправильно.
Этот «архитектурный» подход ближе всего к MVC с введением слоя Сервисов. Который в свою очередь вертикально разделяется на Query и Command.
Ну и фишка этого подхода в том, что Query или Command выполняет только одну задачу. Это позволяет не иметь конфликтов при разработке.
Собственно вся суть подхода описана в этом комменте.
Тут тоже наверное не вполне адекватно сформулировал.
Отдельный контроллер будет для сущности Заказ. И отдельный для сущности Товар.
Дальше дробить пожалй нет смысла.
Задачи разные да.
Они находятся в одном слое с точки зрения отдаления от пользователя.
В какой-то момент этот эффект перестанет работать и это правильно.
Интересная мысль. Спасибо.
Эффект Даннинга -Крюгера был лишь отправной точкой в моих рассуждениях.
Можно уйти в чистый фронтенд, а не пытаться быть фуллстеком. И во фронтенде выбрать конкретный фреймворк. Это сильно снижает скорость увеличения К2 в других областях. Правда может увеличить в конкретной области.
Но в конкретной области знаний К3 ограничен. То есть должно получится так K1 -> K2 -> K3. Но конечно же это всего лишь теория.
Справедливое замечание. В этой статье математики чуть больше чем в описании эффекта Даннинга-Крюгера. Там ее не было вовсе, а тут целая одна формула.
С ходу не нашел. Буду крайне благодарен за ссылку. Очень интересно почитать.
Я не ограничиваю. Мне уютно в Долине Отчаяния.