> Лютая ненависть к повторению кода и велосипедам;

вот из-за таких людей люди делают говно.

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

На собесах на бизнес аналитиков есть упражнение на эту тему - тебя садят и просят написать ТЗ на покупку стула. То есть вот "мне нужен стул, у тебя есть возможность задать мне 3 вопроса, в результате должно быть ТЗ"

вот ответь на вопрос - чем тебя не устраивает дублирование кода? Менеджеры по голове бьют? Какие проблемы дублирование вызывает в реальности?

правило трех не просто так придумали. А потому что ты когда видишь похожие вещи это еще не значит что это дублирование. Нарушение DRY чаще всего выражается не в виде дублирования кода, что иронично немного даже. Зато вот такие вот "лютая ненависть к дублированию" обычно приводит к очень высокой связанности кода где вносить изменения безопасно невозможно (особенно при отсутствии тестов, с тестами херовый дизайн не так стремно фиксить, а вот с дублированием без тестов жить менее опасно)

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

еще люблю цитировать Джо Пэттона на эту тему (автор user story mapping)

https://bukrate.com/set_images/images?id=1426902&author=946670&type=20

Дублирование дублированию рознь. Тебеж написал, без DDD, тестов и вот этого всего. Нужен просто MVP для проверки гепотизы. Ты щас весь обмажешься DDD, потратите кучу времени на моделирование предметной области, выделение ограниченных контекстов, разработку юбикитус лангвидж. И, в лучшем случае через 3 месяца зальете это дело в прод. А рыночку оказалось пох на твой супер-пупер мега архитектурно правильный проект и с тем, как рынок твое решение "принял" вложенные бабки окупятся лет через 10...

Всем привет ребят, есть проблемка, после разворачивания проекта получаю ошибку Fatal error: Uncaught PDOException: SQLSTATE[08006] [7] could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 54326? подключение к БД PostgreSQL можете подсказать в чем может быть причина данной ошибки?

Развернул в докере?

Да

Тогда используй имя сервиса в docker-compose вместо 127.0.0.1.

И в целом бы почитать, как работают bridge сети докера.

Используйте имя контейнера базы данных вместо урл в конфигах.

Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 54326?

Это все да но все же чё там за дублированию рознь?)

Когда вместо того, что бы сделать какую-то общую фабрику по созданию объекта, в которой будут описаны все бизнес-правила создания данного конкретного объекта - ты это херачишь в контроллере, потом в конскольной команде, потом ещё где-то в сервисе и еще где-то в API-контроллере. И ещё в довесок где-то в репозитории.  Да всё что угодно можно нахуякоть тупой копипастой. Если у тебя изначально нет ограниченных контекстов, разделения на слои и вот это вот всё, то лучше высокая связанность чем копипаста портянок кода.

высокая связанность НИКОГДА не лучше. Дублирование легко детектить и устранять. связанность фиксить пиздец тяжело. Если тебя парит "time to market" то лучше копипаста а когда уже будет понеятно что проект не умер можно уже заняться различными вещами типа убирать дублирование.

высокая связанность же приводит к тому что изменение в одном месте приводит сразу к каскаду в других - это сильно замедляет тестирование и негативно аффектит твой любимый тайм ту маркет. С дублированием ты можешь "забыть" что-то подправить (что тяжело - сегодня IDE тебе уже подсвечивают дубли и описанный тобой кейс это прям не часто случается и оочень легко выносится в сервис с одним методом) что опять же обычно крайне легко найти и очень предсказуемо  

повторюсь - дублирование очень дешевая проблема. Ее грех лишь в том что дублирование слишком легко увидеть

Золотые слова

+

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

Я подозреваю, что автор ТЗ имел ввиду как раз такое тупое дублирование. Везде и всюду нужно соблюдать баланс. Если эта часть кода не переиспользуется и в неизвестно когда должна будет переиспользованна и будет ли вообще, то можно писать прямо. Если что-то нужно продублировать, то тут уже лучше подумать, как это правильно организовать.