С разработки архитектуры БД. Если это дейстивтельно заказ, а не 3 строки.

Вот как раз ровно для этого! ) Я надергаю сервисов из других проектов и соберу заказчику его ТЗ процентов на 70, за пару дней. А для того, чтобы сервисы за собой не тащили километровую мотню, нужна хорошая архитектура проекта, слабосвязанная.

Сам факт рефакторинга (пардон) уже говорит об архитектурных ошибках. =)

Только если взят в реализацию антипаттерн "излишняя гибкость". Там он не один, скорее это группа.

Пять уровней абстракции позволяют хорошо разделить контексты и обеспечить полиморфизм - залог гибкости и расширяемости системы. Вот они:
1. Контроллеры
2. Модели (в понимании объектов, содержащих свойства сущности. И их правила валидации)
3. Слой сервисов. То место где пишется бизнес-логика.
4. Слой работы с БД. Просто набор методов с запросами. (getUserInfo() ну и так дальше).
5. Уровень представления. Обеспечивает абстракцию над схемами вывода (шаблонизаторы, генераторы PDF, упаковка в JSON и т.д.)

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

Что здесь лишнее?

Да ладно
Это тоже твое частное мнение. А вот допустим Фаулер говорил, что код нуждается в рефакторинге уже после написания первой строчки. И есть даже схема разработки через рефакторинг. И даже название есть. "Эволюционное проектирование". О каких ошибках архитектуры ты говоришь?

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

Ну наверное для тебя ничего, раз тебе так удобно. Вопрос не в том, что лишнее. Вопрос в том, что это теория. Теоретически, теория и практика неразделимы. На практике все в точности до наоборот.

Вопрос в том, что это не серебряная пуля. А просто привычная тебе схема. С кучей изъянов, если рассматривать с другой колокольни.

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

Но это тоже мое частное мнение. Я не собираюсь сейчас разбирать эту схему. Я говорю только об одном. Попытки унифицировать приложение (не фреймворк), сделать его гибким и расширяемым, полиморфным, как ты говоришь, это в большинстве случаев никому не нужное и никогда не востребованное усложнение на самом деле. Хотя в теории кажется все гладко.

По мне так удобнее, когда код легко поддается рефакторингу, а не расширяемости. Ибо расширение влечет за собой увеличение и усложнение кода. А рефактоинг как раз наоборот - упрощение и уменьшение объемов. Ибо то, что не нужно - безжалостно выкидывается. Когда нужно - добавляется. А не плодятся веревки наследований, делегирования, декорирования и прочей лабуды.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Это как так? То есть практика никогда не совпадает с теорией? )))

Теперь о рефакторинге. Это не добавление нового функционала и не исправление старой бизнес-логики. Рефакторинг есть переписывание кода без изменений ТЗ, скажем так. На кой ляд может понадобится рефакторинг если нет архитектурных ошибок?

Ну только если рефакторить говнокод. В других случаях уменьшение объемов всегда ведет к усложнению.

Ссылку на определение в википедии, пожалуйста. ))

Немного не так. Не просто с умом, а так, как удобно тебе. И никому иначе. Об этом и шла речь. Тебе удобно писать как в симфони - твое право. Но это никакая не общая практика. Это частная практика, не более того.

Очень часто не совпадает. Тем более теорий куча, у каждого своя. А на практике это не всегда оптимально и вообще применимо.

Ладно, согласен. Определение не совсем уместное. Я просто не знаю определения, обратного расширемости. Рефакторинг более-менее подходит, так как это не наращивание функционала, а внутреннее изменение системы.

На тод ляд, что архитектура может (и очень часто) изменяется даже в процессе разработки. Я же написал:

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

Офигенный вывод. Ну во первых, все равно получится говнокод. Как бы ты не пыжился, как бы не называл красивыми словечками типа "пять слоев абстракции", "полиморфизм" и прочая, в итоге код будет красив только для тебя. Любой другой разрабочик обязательно найдет подванивающие места и заявит - "я бы руки отрывал!" И будет прав. Ибо читай п.1.

А во вторых, когда же это было, чтобы уменьшение объема кода вело к усложнению? Не, я понимаю, что можно написать все на тернарниках и в одну строку. Но не нужно утрировать. Изменить функционал без рефакторинга можно разными способами. Наследованием или декорированием к примеру. А это новые классы, переопределения методов, добавление новых с оставлением старых, которые уже не нужны. И это упрощение??? А переписать исходный класс так, что бы остался толко нужный функционал, заточенный под конкретную задачу - это усложнение???

Ну тогда я не знаю.

Вот что Боб Мартин сказал по поводу предварительного программирования:

Причем тут википедия? Просто ссылку могу дать. Изучай.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.