ну расскажи мне какой профит мы получаем от того что юзаем шаблон репозиторий и при этом юзаем active record?

Профит использования репозиториев и других вещей - в инкапсуляции. Если претензии именно к названию "Repository поверх AR", то замените его на какой-нибудь "EntityManager поверх AR" и все недопонимания отпадут. В данном случае репозиторий делегирует сохранение в ActiveRecord. Но простым переписыванием сущности и репозитория строка $order->save() в репозитории за один час превращается в $this->em->persist($order) или $this->pdo->execute('INSERT ...'). Без переписывания сотен контроллеров, тестов и хэндлеров.

https://github.com/ElisDN/yii2-demo-shop/blob/master/shop/cart/Cart.php#L43 казалось бы, ну возьми хэш

Взял. $item->getId() - это и есть хэш.

учеличивает каунтер потерв пмодификатор

Это конструктор строки CartItem, записывающий каунтер и модификатор. Ничего не теряется.

ну 2 вещи разного цвета второй цвет потеряется

Две вещи разного цвета - это два modification_id в выпадающем списке "Выберите модификацию". Ничего не теряется.

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

В demo-shop сделано именно так. К товару "IPhone X" добавляется целиковая модификация "Space Gray 256GB" со своей ценой и количеством. Если давать выбирать "Цвет" и "Память" отдельно, то придётся реализовывать такую же систему совместимости характеристик, чтобы указать, что белых на 64 гига имеется 8 штук. Назвать её, например, Combination. И это... окажется как раз самой нашей Modification.

В demo-shop сделано именно так. К товару "IPhone X" добавляется целиковая модификация "Space Gray 256GB" со своей ценой и количеством. Если давать выбирать "Цвет" и "Память" отдельно, то придётся реализовывать такую же систему совместимости характеристик, чтобы указать, что белых на 64 гига имеется 8 штук. Назвать её, например, Combination. И это... окажется как раз самой нашей Modification.

Думал сделать 3-4 таблицы 1. products 2. modifications(тип модификации, и значение её(красный, 32gb)) 3. modification_groups(цвет, обьем) 4. product_modifications(связь между modifications и product), и тут же настройки(использовать родительские характеристики, использовать родительское описание и т.д.), поля тут примерно такие: modified_id(модифицируемый товар), modification_id(товар модификация), и прочие настройки

почему yii если он говно Не знаю, что скажет Дмитрий, но на yii можно все сделать в два раза быстрей, чем на любом другом фрейме Можно начать говорить об архитектуре yii, что у него конфиги из массивов и бла-бла-бла Чистота кода зависит от программиста, а средств yii хватает для всего Кроме этого он быстрей и легче laravel и symfony <4

> на yii можно все сделать в два раза быстрей, чем на любом другом фрейме Если под словом "всё" подразумеваете только генерацию CRUD-ов по готовой БД под встроенный Twitter Bootstrap, то "фигачить" можно хоть по сайту в час. Если ваш код на 100% собран из CRUD-ов и в нём 0% своей бизнес-логики, то это актуально. Можно собрать сайт за два дня вместо четырёх. Это круто. Если же пишем бизнес-приложение с логикой, то там помимо этого уже нужно сочинять и свой программный код. Если на 10% CRUD-ов получается 90% своей уникальной логики, то ускорения уже не заметите. Может сделаете за 176 дней вместо 180, но это на таких масштабах уже мизерная экономия.

почему yii если он говно Не знаю, что скажет Дмитрий, но на yii можно все сделать в два раза быстрей, чем на любом другом фрейме Можно начать говорить об архитектуре yii, что у него конфиги из массивов и бла-бла-бла Чистота кода зависит от программиста, а средств yii хватает для всего Кроме этого он быстрей и легче laravel и symfony <4

> Можно начать говорить об архитектуре yii... Чистота кода зависит от программиста, а средств yii хватает для всего Вот из-за такого непонимания объекта спора и вытекают все "бла-бла-бла". Давайте всё-таки разделять: Чистота и удобство *своего* кода зависит от программиста. Чистота и удобство *кода фреймворка* не зависит от программиста. Со своим кодом проблем нет. Все "затыки" происходят при попытках взаимодействия с кодом самого Yii.

Профит использования репозиториев и других вещей - в инкапсуляции. Если претензии именно к названию "Repository поверх AR", то замените его на какой-нибудь "EntityManager поверх AR" и все недопонимания отпадут. В данном случае репозиторий делегирует сохранение в ActiveRecord. Но простым переписыванием сущности и репозитория строка $order->save() в репозитории за один час превращается в $this->em->persist($order) или $this->pdo->execute('INSERT ...'). Без переписывания сотен контроллеров, тестов и хэндлеров.

по поводу em->persist - при добавлении новых записей все как бы ок. Более того, если бы у тебя была демонстрация сохранения всего агрегата в репозитории - тоже было бы ок. Вопрос по изменению сущностей. И тут начинается веселье

Какое веселье?

зачем пытаться за "час" выпрямить AR и его проблему с SRP, если за пол часа можно взять и прикрутить DM ?

у меня чуть другой вопрос - почему нельзя в рамках одного проекта использовать и DM (для write части) и AR (для read части оно хорошо подходит)

почему "репозиторий" а не демонстрация "вот мы персистер для нашего агрегата запилили"

туда же можно было бы весьма быстро впилить и что-то типа UoW что бы за связями следить

потом продемонстрировать как в рамках одной операции можно работать с несколькими агрегатами, разедление на контексты в данном проекте вообще нет

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

Кому чат по теоркату

@ru_catheory

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

если же несут - давай рассуждать)

p.s. и все же демонстрировать DDD на yii это какой-то очень странный фетиш

та че, в том году доклад был

про DDD в yii))

от Науменко?

да

DDD просто о сложном

да, и он тоже запорол объяснение что такое DDD (хотя хорошие примеры были относительно тех же VO)

ну и.... там у него тоже идеология а не прагматизм

но там тебе и контексты чуть-чуть были, и много чего еще

зачем пытаться за "час" выпрямить AR и его проблему с SRP, если за пол часа можно взять и прикрутить DM ?

Всего-лишь убрали валидацию из AR и подключили relation-behavior. Если бы всё натащили из Symfony, то это уже бы не был "мастер-класс по Yii" :) А про подключение Doctrine есть отдельный цикл http://www.elisdn.ru/blog/104/domain-entities-modelling

у меня чуть другой вопрос - почему нельзя в рамках одного проекта использовать и DM (для write части) и AR (для read части оно хорошо подходит)

Можно.

Можно.

нет, мне то понятно что можно)

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

мне это кажется весьма и весьма занятным ибо.... это провоцирует использовать либо недостаточно сложное решение там где оно оправдано (AR vs DM) либо юзать везде решения с самой высокой сложностью для всех видов операций просто потому что для одного места из 3-х это было оправдано а дальше надо делать одинаково

так же

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

этого говна и так на гитхабе много

DDD просто о сложном

там было слишком мало про ДДД, больше про сущности. идея доклада по ДДД это так себе идея изначально, ну вот не реально, даже поверхностно объяснить за 30-45 минут

то что на сотнях страниц разных книг написано

нормально можно рассказать только про какую-то часть, например по контексты, про единый словарь

там было слишком мало про ДДД, больше про сущности. идея доклада по ДДД это так себе идея изначально, ну вот не реально, даже поверхностно объяснить за 30-45 минут

в одном из многочисленных видосиков на тему DDD было одно очнь короткое и емкое описание идеи DDD и объяснение почему так сложно показать проект с DDD - "it's about journey, not destination".

ну и Уди очень неплохо в своем докладике про "if the deciver" тоже весьма неплохо описал суть

так что я думаю тут больше желание покрыть ВСЕ! и что такое сущности и контексты, и VO, и репозитории зачем нам, и зачем отделять персистентность от бизнес логики и т.д.

вот это приводит к проблемам

еще больше меня радует подход "репозитории упрощают тестирование".... я нигде не видел примеров на тех же yii или laravel экспуатирующих для тех же целей row data gateway котороое ложится чуточку лучше на AR

еще больше меня радует подход "репозитории упрощают тестирование".... я нигде не видел примеров на тех же yii или laravel экспуатирующих для тех же целей row data gateway котороое ложится чуточку лучше на AR

но ддд може быть и без "репозиториев" в том же yii и laravel

но ддд може быть и без "репозиториев" в том же yii и laravel

может, и успешно может, от того и бомбит у меня)

нет никаких проблем запилить UoW под AR, точно так же нет никаких проблем с сущностями и AR если последнее используется тупо как модель данных. тогда и SRP не нарушается и все хорошо

но это же не мэйнстрим

сделаем вид что есть только 2 подхода

и все

> запилить UoW а зачем?

что мешает тебе обернуть все в транзакцию?

агрегат сохранять) ну то есть это может быть не совсем UoW а персистер твоего агрегата

что мешает тебе обернуть все в транзакцию?

надо save как-то дергать)

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

Почему-то у многих по слову "репозиторий" сразу всплывает маниакальный рефлекс поиска какого-то "идеального супер-DDD", где обязательно должны быть контексты, спецификация и прочие полутехнические вещи. DDD - это всёго лишь методология и набор рекомендаций поверх неких паттернов и классических принципов, говорящая "Программируй и называй всё так, как это происходит и называется в моделируемом тобой реальном мире". > контексты - без демонстрации идеи контекстов любой пример DDD не стоит ничего Здесь всего один контекст "Магазин". Если требуется более сложная модульная архитектура с контекстами магазина, форума и блога, то тогда и разделим сущности и будем использовать события с медиатором как в http://www.elisdn.ru/blog/86/module-relations-on-yii2

Почему-то у многих по слову "репозиторий" сразу всплывает маниакальный рефлекс поиска какого-то "идеального супер-DDD", где обязательно должны быть контексты, спецификация и прочие полутехнические вещи. DDD - это всёго лишь методология и набор рекомендаций поверх неких паттернов и классических принципов, говорящая "Программируй и называй всё так, как это происходит и называется в моделируемом тобой реальном мире". > контексты - без демонстрации идеи контекстов любой пример DDD не стоит ничего Здесь всего один контекст "Магазин". Если требуется более сложная модульная архитектура с контекстами магазина, форума и блога, то тогда и разделим сущности и будем использовать события с медиатором как в http://www.elisdn.ru/blog/86/module-relations-on-yii2

так, "магазин" это не контекст, это контекстище

Row data gateway разве почти не то же самое самое что и AR, сущности только с состоянием, так это в основном на yii и практикуется, а сервисы используют для логики

Row data gateway разве почти не то же самое самое что и AR, сущности только с состоянием, так это в основном на yii и практикуется, а сервисы используют для логики

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

просто процесс гидрации отличается

ERROR: S client not available

это и на тестировании как раз таки позитивно сказывается

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

агрегат сохранять) ну то есть это может быть не совсем UoW а персистер твоего агрегата

Ну так у меня и в AR весь агрегат сохраняется.

Ну так у меня и в AR весь агрегат сохраняется.

бихейвером

не столь важно, меня сейчас больше интересует то как ты трактуешь "что такое контекст"

ибо "контекст блог" и "контекст магазин" уже о многом говорят

https://github.com/ElisDN/yii2-demo-shop/blob/master/shop/entities/Shop/Product/Product.php

я насчитал тут 4 зоны ответственности + нарушение OCP

эх жалко что юнит тестов на этот класс нету

я насчитал тут 4 зоны ответственности + нарушение OCP

а как там OCP нарушается?

https://github.com/ElisDN/yii2-demo-shop/tree/master/shop/tests/unit/entities/Shop/Tag - очень интересное решение... не знаю специально ли ты демонстрируешь что "не надо завязывать тест кейс на том какой класс мы тестим а лучше завязывать на тестируемом поведении" или так вышло случайно

а как там OCP нарушается?

OCP в случае сущностей, если мы выделяем контекстища вля "магазин", нарушить легко и просто) сам подумай)

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

но вообще - добавится у тебя еще что-то и тебе придется менять эту сущность. Полностью OCP соблюсти тут нереально, это даже не стоит пытаться делать, но можно сильно уменьшить количество вариантов почему нужно править

OCP в случае сущностей, если мы выделяем контекстища вля "магазин", нарушить легко и просто) сам подумай)

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

ну скорее у тебя увеличивается потенциал для расширения в силу нарушений SRP

они ж рука обруку идут...

нарушение SRP - это по сути снижение кохижена нашей сущности. И оно повышает связанность (те же теги, фотки и т.д.)

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

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

(вроде ж на хабре была статья где чувак говорит что анемичные сущности это все по SOLID)

хотя по факту это сделает все еще хуже

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

так а толку, просто место изменения переносишь

с одного места в другое

именно! в корень зришь) и кохижен снижаешь и каплинг еще больше увеличиваешь)

ибо "контекст блог" и "контекст магазин" уже о многом говорят

Изначально без контекстов есть просто сущность User и в ней собраны ответственности аутентификации, покупателя и т.п. В большом проекте приходим к нарушению SRP и получению God Object с сотнями методов и связей. Усложняется класс и его тестирование. Для борьбы с этим приходит на помощь разбиение на контекты как в указанной статье. Агрегат User для работы в соответствующих контекстах как "пользователь" в процессах аторизации, "покупатель" в процессах магазина, "участник форума" и "автор блога" мы разбиваем на отдельные сущности User, Buyer, Author и Member и перемещаем в них только нужные им данные и поведение и т.п.

Изначально без контекстов есть просто сущность User и в ней собраны ответственности аутентификации, покупателя и т.п. В большом проекте приходим к нарушению SRP и получению God Object с сотнями методов и связей. Усложняется класс и его тестирование. Для борьбы с этим приходит на помощь разбиение на контекты как в указанной статье. Агрегат User для работы в соответствующих контекстах как "пользователь" в процессах аторизации, "покупатель" в процессах магазина, "участник форума" и "автор блога" мы разбиваем на отдельные сущности User, Buyer, Author и Member и перемещаем в них только нужные им данные и поведение и т.п.

ты меня успокоил

Изначально без контекстов есть просто сущность User и в ней собраны ответственности аутентификации, покупателя и т.п. В большом проекте приходим к нарушению SRP и получению God Object с сотнями методов и связей. Усложняется класс и его тестирование. Для борьбы с этим приходит на помощь разбиение на контекты как в указанной статье. Агрегат User для работы в соответствующих контекстах как "пользователь" в процессах аторизации, "покупатель" в процессах магазина, "участник форума" и "автор блога" мы разбиваем на отдельные сущности User, Buyer, Author и Member и перемещаем в них только нужные им данные и поведение и т.п.

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

в каких ситуацих выделял бы эти контексты (и дробил бы еще больше)