если я делаю монолитное приложение достаточно использовать AppBundle для проекта?

у тебя будет просто src без бандла

удалил все таблицы, пытаюсь запустить миграции и вылезает ошибка [Doctrine\DBAL\Schema\SchemaException] The table with name 'react.category_product' already exists.

хотя таблиц в бд вообще нет

соответственно гдето две миграциис созданием схемы?

папку миграций я тоже почистил

console cache:clear пробовал?

bin/console cache:clear --no-warmup

энвайронмент не забывай указать

http://imgur.com/a/CC3sZ

у тебя падает на migration diff?)

угу

я мигрировал первый раз и понял что ошибся в анотациях, и 2 пивотные таблицы создал: product_category, category_product. Потом удалил используй сиквелПро таблицы

и все. больше не работает

подобные ошибки для diff не свойственны, это только если у тебя осталась какая-то инфа в кэше о структуре базы (кэш доктрины), но тут хз. Проверяй по пунктам что и как ты делаешь. Коллизии имен таблиц и все такое

а в базе таблиц нету?

просто diff вообще не должен ругаься на то что что-то уже есть в базе

он же diff, он сравнивает мэппинг и текущную структуру

так что возможно проблема с мэппингом

хм

не помню как называется команда для валидации мэппинга

пробуй удалить весь app/cache

вручную

bin/console doctrine:schema:validate ругается

щас найду ошибку

в общем проблема была в аннотации. Решил сделать many-to-many и в двух сущностях указал анотацию https://paste.laravel.io/PyxXG

ну соответсвенно сменив значения. так понял это не корректно?

ну сам подумай)

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

это не так работает)

не может быть двухсторонней равнозначной связи?

что по твоему означают mappedBy и inversedBy?

inversedBy указывается для главной модели

не совсем

вообще старайся по возможности вообще не делать двусторонних связей

и разберись по документации как это работет

Блин, в убой не понимаю DDD... О_о

книжек почитай

пытаюсь... но как доходит до реализации - хавайся

ща вот снова буду пытаться... нарыл книжку 2017 года DDD in PHP

https://www.amazon.de/Domain-Driven-Design-PHP-Carlos-Buenosvinos/dp/1787284948/ref=sr_1_fkmr0_3?ie=UTF8&qid=1503314999&sr=8-3-fkmr0&keywords=DDD+in+PHP

лучше красную и синюю сразу почитать

синюю знаю, а что за красная? )

https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/ref=sr_1_3?ie=UTF8&qid=1503316879&sr=8-3&keywords=domain+driven+design

О! пасиб... не видел ее

хм... это ведь она же? https://www.amazon.de/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420/ref=sr_1_1?s=books-intl-de&ie=UTF8&qid=1503317009&sr=1-1&keywords=domain+driven+design+distilled

только типа более новая?

не, другая. не читал ее еще

ой, не, сорри

Для первоначального обзора можно прочесть https://www.infoq.com/minibooks/domain-driven-design-quickly

добрый день, подскажите пожалуйста какие рабочие бандлы есть для работы (парсинг/генерация) Excel, обязательно оба формата (.xls, .xlsx) ?

зачем бандлы? https://github.com/PHPOffice/PHPExcel

добрый день, подскажите пожалуйста какие рабочие бандлы есть для работы (парсинг/генерация) Excel, обязательно оба формата (.xls, .xlsx) ?

https://stackoverflow.com/a/3931142

Блин, в убой не понимаю DDD... О_о

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

короч DDD это когда ты можешь прочитать бизнесу код как прозу и он все поймет

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

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

ну и еще неплохо работает в купе с BDD на проектах где предметная область все еще формируется

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

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

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

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

представь что их нет

или сделай в коде так что бы так казалось)

ну и еще - а ты уверен что оно тебе надо?

самое сложное в DDD понять сам этот свод правил. столько сложно понятных терминов и правил.

видимо все дело в том что рускоязычные термины не нативны для нас.

ERROR: S client not available

хотя в вики более менее переведено.

Сводный корень - аггрегат?

Сводный корень - аггрегат?

корень агрегата по идее

не знаю зачем тебе изучать переведенные термины

ну так хз зачем это в вики написали

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

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

поправь)

Блин, в убой не понимаю DDD... О_о

На хабре размазано написано про DDD https://habrahabr.ru/post/316438/

так может ну его нафиг тогда ))

и без него отлично можно жить

я для себя из DDD взять именование переменных, методов

согласно бизнесу называю все

ну тут главное не увлекаться а то переменные по 20-30 символов это тоже дичь

и без него отлично можно жить

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

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

вообще основная идея это - решение какой-то бизнес проблемы

>а потом дорого, сложно и не работает

а чтобы решать бизнес проблему - нужна модель бизнеса (Domain), те должна воспроизводить все бизнес процессы

и все единые языки, анализы предметной области это сюда

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

а чем меньше сложность тем дешевле система

кароч, не обязательно захломлять свой код сервисами, командами, репозиториями и тп ибо это в ДДД... можно спокойно иметь минимальную модель, которая описывает предметную область, с использованием той же Active Record, без сервисов и вызовом aggregate root в контроллерах

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

типо code first подход

а потом, если инфтраструктура начинает очень сильно влиять на домен, то уже начинать думать, о декомпозиции и разделении

кароч, не обязательно захломлять свой код сервисами, командами, репозиториями и тп ибо это в ДДД... можно спокойно иметь минимальную модель, которая описывает предметную область, с использованием той же Active Record, без сервисов и вызовом aggregate root в контроллерах

зачем =) ? можно же на wp все писать? ) прмиерно это я и имел ввиду

зачем =) ? можно же на wp все писать? ) прмиерно это я и имел ввиду

у меня походу слишком плохо с сарказмом)) ну тут уже зависит от бизнес модели, для каких целей реально можно взять wp или magento и не парится

все зависит от кол-ва бабла и времени)

>кароч, не обязательно захломлять свой код сервисами, командами, репозиториями и тп ибо это в ДДД... можно спокойно иметь минимальную модель, которая описывает предметную область, с использованием той же Active Record, без сервисов и вызовом aggregate root в контроллерах +1 иногда это нафиг ненадо. и меня удивляют люди которые готовы башку об стену разбить утверждая что AR это антипаттерн. Блин оно работает и решает проблемы бизнеса

ну оно работает это не аргумент) когда-то мы писали свои велосипеды без мвц и фремворков и оно тоже работало и решало бизнес задачи)

а что аргумент?