точку входа интерфейса D в M2 в можно сократить до одной*

чта?

а класс D в конфиг

чта?

например, как тут https://github.com/videlalvaro/RabbitMqBundle#usage

consumers: upload_picture: connection: default exchange_options: {name: 'upload-picture', type: direct} queue_options: {name: 'upload-picture'} callback: upload_picture_service class UploadPictureConsumer implements ConsumerInterface

....

ты не понял проблему

судя по всему

>с ним идет общение через фасадный класс A это чтоли?

это вообще надо выкинуть

меньше абстрации - меньше проблем

привет ребята

меньше абстрации - меньше проблем

меньше связанности - меньше проблем)

All hail SOLID!

т.е предлагаешь завести интерфейс, его заюзать и проблема ушла? так получается к модулю будет 2 точки входа при том что на разных уровнях модуля

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

версионирование

это все надуманные проблемы

возможно

это все от переизбытка свободного времени

бизнесу-то все равно сколько точек входа в модуль

работает и не ломается - главное

более реальный пример, доктрина у тебя есть EntityManger, который умеет делать и commit, и transactions, и запросы дает тебе делать. раздутый немного, но не в том вопрос. штука в том что тебе не нужно знать о коннекшенах, о UoW, о метадате, фабриках репозиториев, как он работает с конфигами, кешем и тд. у тебя есть один простой интерфейс а вот если ты надумаешь что-то юзать в обход, окажется что этот метод стал депрекейтед и тд, или вообще поменялся был случай с кроликом. из ядра взяли класс, унаследовали и переопределили, впихнули свои костыли для реконнектов и в один прекрасный момент у нас все сломалось. всего то обновили минорчики в либах, в ченжлогах везде было пусто т.к это интерналы. а проблема была в том что они просто захотели поменять реализацию у себя

работает и не ломается - главное

меньше гибкость - дольше внедрение новых фичей и тд

бизнесу-то все равно сколько точек входа в модуль

если бизнесу пофиг в процедурках ты пишешь или нет, соблюдаешь ли ты SOLID, используется ли DDD и тд - зачем тогда это все?) много времени у людей и решение проблем которых нет или наверное зачем-то это все нужно?

чтобы не скучно совсем было

в каком-нибудь софте для станка на заводе нет же DDD

или есть?

в станке не факт что вообще есть какой-то софт

ну всякие лазерные чпу

или типа того

я не владею информацией что в них есть)

в ядре линухов тоже нет DDD, но они придерживаются своих принципов

ну и вопрос не в DDD, а в дизайне кода

Если хотите, могу зеркало запилить

?

> в ядре линухов тоже нет DDD почему ты так считаешь?) если инфраструктура и есть твой домен

хотя я честно хз)

это все от переизбытка свободного времени

бизнесу все равно как ты делаешь дела, если только то как ты делаешь дела не вызывает убытки. Я уже приводил пример. Сделал так, пришли запланированные изменения о которых разработчик не знал, вылелось в рефакторинг + тестирование, всего командой было потрачено лишних 36 часов, по рейту $100/h для бизнеса это обошлось в лишние $3600

и это была довольно простая ситуация

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

ну и вопрос не в DDD, а в дизайне кода

так никто не думает об этом, потому что профита меньше, чем затраченного времени

народ на 5.3 сидит в основном

как сказать, если думать только о "здесть и сейчас", то далеко на проекте не уедешь дальше прототипа

лично я видел как умирали проекты из-за этого

которые приносили прибыль

ну так пока думаешь как сделать правильно, деньги не зарабатываешь

и были не в состоянии быстро внедрять что-то

вкрутил как есть, а дальше уже можно думать

>а дальше уже можно думать когда дальше?) когда все превратилось в спагетти и распутывать все очень тяжело?

народ на 5.3 сидит в основном

сейчас не 2012й год вроде

https://seld.be/notes/php-versions-stats-2016-1-edition

оказалось все лучше

5.6

May 2016 PHP 5.6 39.67% PHP 5.5 29.56% PHP 7.0 20.24%

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

так я о полезности кода и говорю

полезности в плане денег

stack overflow вон как убого сделан

у них там монолит

я не знаю как кроме как стабильностью и скоростью внедрения кода можно сделать соотношения - полезность/деньги

я не знаю как кроме как стабильностью и скоростью внедрения кода можно сделать соотношения - полезность/деньги

в лоб измерять

монолит быстрее сделать

> Ilya Gusev, [Nov 27, 2016, 16:43]: stack overflow вон как убого сделан > у них там монолит

но со воей задачей он справляется целиком и полностью

а кто говорит что монолиты это плохо?)

монолиты - это хорошо

ERROR: S client not available

ты всегда должен стараться делать монолиты

плохо - это спагетти, это простыня кода, нечитаемый код

лазанья еще хуже

@fes0r выше говорил

про CoreBundle

у меня много где однобандловая структура

ну так это best practices

ну это значит что ты хреново дробишь систему)

только я AppBundle называю

я тоже так делал)

не, когда у тебя AppBundle и больше других бандлов нет - это хороший такой монолит

а когда у тебя AppBundle, userBundle, NewsBundle, ShitBundle

и все юзает что-то друг у дружки

спагетти, не?

то на самом деле это просто папки и никакого разделения там нет

так

погоди

а куда, например, Utils пихать

всякие микроштуки

> а куда, например, Utils пихать никуда?) их не должно быть)

ну или это инфраструктура

тогда опять же должно быть конкретное название

аля

Queue

для очередей

причем обработка задач из очередей это уже другая штука

ну вот например

ты реально бандлы юзаешь?

расскажи что у тебя будет лежать в UserBundle?

ты реально бандлы юзаешь?

у меня чувак в команде есть, он тоже бандлы любит. Но у него нет CoreBundle и потому ему одному в моей команде так можно)

а неймсмпейсы чем не годны?

расскажи что у тебя будет лежать в UserBundle?

объекты в которые маппятся данные о пользователях и сам сервис для их получения