Magento 2 это два фреймворка если быть точным:
— компонентный фреймворк общего использования
— e-commerce фремворк, который построент на нашем фреймворке (пункут 1).
Просто CMS Magento назвать нельзя, не смотря на то, что CMS в самой мадженто есть
Я отвечу на комментарий, который юзер donvictorio оставил, а потом удалил:
именно поэтому 2.0 и 2.1 ветки несовместимы друг с другом и разрабатываются параллельно?
Релизы 2.0 и 2.1 являются коммерческими релизами платформы, а не релизами компонентов. Они вполне могут быть несовместимы между собой. Хотя между 2.0 и 2.1 несовместимости были минимальны. Здесь об этом можно почитать подробней
Такая основная идея связи между версиями платформы и версиями компонентов
в этом и была идея — показать костыль, кстати он и выглядит буквально как костыль. Ввиду больших ограничений, которые привносит обратная совместимость иногда сделать «фикс», качество кода которого будет высокое, и мы не будем наращивать технический долг — очень теяжело. Во второй части стать будут конкретные примеры с кодом и как они должны решаться. И будет эволюция ремонта этого крана, так как в офисе у нас было несколько попыток его починить
уже написал по этому поводу письмо продакт оунерам, отвечающим за бекпорты в 2.0.* и 2.1.* так как фикс обратно совместимый проблем доставить его в эти релизы быть не должно.
Относительно глобальных вопросов, которые Вы затронули:
Или неоднозначные зависимости между данными в тех же store-таблицах или stock-таблицах?
Стоки в Мадженто отдельная история, не зря в офисе весит такой девиз.
Из API интерфейса StockItemInterface знание о вебсайтах убрали. Идеально поля website_id не должно быть в таблице StockItem, т.к. StockItem это не что иное как сущность-связка продуктов к стокам, которое хранит кол-во товара на конкретном стоке. Опять же идеально было бы если бы такую связку мы могли задавать в каком-то скоупе, website только один из возможных скоупов. Пока поле website_id в таблице это рудимент, так как опять же пока еще Magento из коробки поддерживает только один сток. Но с точки зрения индексов сделали, чтобы комьюнити могло самостоятельно писать малти стоковые экстеншены.
почему для EAV заложено только 8 типов сущностей (customer, customer_address, catalog_category, catalog_product, order, invoice, creditmemo, shipment) из которых через админку для расширения доступны только атрибуты продукта (catalog_product)? Почему проигнорированы такие сущности, как admin, authorization, stock, sales_rule, cms, rating, report, review, ...?
Мадженто идет к тому, чтобы любые сущности были расширяемы дополнительными атрибутами. Не только перечисленные вами, а все, включая сущности добавленные сторонними разработчиками. Первый шаг был сделан к этому с добавлением Extension Attributes в Data API интерфейсы. Но пока это нельзя назвать полноценной заменой EAV, потому что программист обязан сам заниматься персистингом и ретривингом данных этого атрибута, что приносит замедление производительности. Поэтому корректное решение в данном случае было бы взять ответственность по сохранению и извлечению атрибута, а также эффективному хранению и фильтрации по нему на сторону Мадженты, а не стороннего программиста.
Но… попробуйте программно сохранить store (Store View в терминах админки), руководствуясь best practices от Magento 2 — не получится. Это при том, что репо-класс для \Magento\Store\Model\Store существует, правда без метода save()
Это известный gap, не могу сказать когда именно он будет исправлен
Они уже становятся правилом (the future is here), так как твит Макса Пронько, который Вы привели посвящен мероприятию, которые называется Magento Contribution Day, которое прошло в Италии (Meet Magento Italy).
Также в ближайшее время подобный ивент пройдет в Хорватии.
Идея простая — представители комьюнити фиксят открытые GitHub issue и вмете с представителями Core Magento Team обрабатывают фикс, ревьювят и вливают в Magento mainline.
Комьюнити вроде бы довольно такой инициативе.
По поводу других комьюнити инициатив также можно прочитать здесь.
Но основная — это то, что выделилась отдельная команда Community Engineering Team, которая занимается процессингом внешних Pull Request-ов. Чтобы максимально уменьшить время ожидания пул реквестов в очереди.
За успехами этой команды можно следить на открытой GitHub борде с PR-ами.
ну и собственно представити комьюнити уже сами начали ревьювить и процессить внешние пул реквесты.
Об этом в ближайшее время будет отдельный пост на Хабре.
Вы должны понимать, что Magento и Woo сложно назвать прямыми конкурентами. Так как они конкурируют за разные сегменты рынка. Woo нацелен на очень маленького продавца, в то время как Magento 2 начала ориентироваться на мерчанта с годовым оборотом 20+ млн. $ при этом удерживая сегменты, которые заняла М1. Oro изначально себя позиционировал как В2В решение, а не В2С. В Magento 1 не было предложений для В2В из коробки вообще. Посмотрим, как М2 отреагирует на это в ближайшее время. Пока же можно смело говорить, что наибольшим конкурентом для Magento 2 на рынке является Magento 1
В статье прекрасно все — от методов дебагинга через дамп в файл, до исправлении бага в core файле магазина.
Хотя судя по этому листингу Prestashop их код особо и не расчитан, чтобы его нормально кастомизировали и правили
ну если речь о сущностях, тогда в вашей реализации проблемы, так как ваши сущности отдают наружу доступ ко всем смоим данным и тем самым нарушают инкапсуляцию.
Контракт сущности (entity) не должен состоять из getter/setter к данным из которых эта сущность состоит
DTO который содержит пачку геннеров и сеттеров — это не всегда плохо, точней если он используется для межпроцессной коммуникации (например в web api), то это даже хорошо.
Поэтому может просто имеет смысл выделить отдельную сущность — доменную модель. А DTO оставить как DTO. Сериализируемый объект, который всегда можно передать по сети.
то что вы говорите — не применимо и не правильно.
у вас в квери сценарии будут какие-то недоинициализированные сущности, с нерабочими интерфейсамми, которые кидают эксепшены на вызовах определенных методов.
В этом и фишка CQRS — у вас две архитектуры, для чтения и записи. И масштабируете вы их тоже отдельно. Это не недостаток, а достоинство подхода. А вы хотите это нивелировать, пытаясь это уложить на одну кодобазу.
идея в том, что для операций чтения, которых в большинстве приложений сильно больше чем записи вы можете иметь отдельную упрощенную структуру данных, т.е. Query операции вам возвращают просто массив данных key=>value или массив DTO. А в Command у вас полноценные модели, с процеркой всех валидацией и тяжелыми связями для обеспечения консистентности
В CQRS подходе DDD у вас живет только в коммандах, квери должны быть очень упрощенными и быстрыми.
Как правило с отдельным индексом и без тяжелого ORMа
то что вы написали, это реализация фабрики. Билдер это как раз про цепочки сеттеров.
А по поводу вопросов дороговизны. Если ваши сущности иммутабельны, т.е. не изменяемы, то вы вполне можете их шарить по всему приложению, так как никто не сможет их поломать изменив глобальный стейт. И у вас есть некий Object Manager — глобальный контейнер в который кладутся уже созданные сущности и который отвечает за создание новых, которые требуются параметрами конструкторной dependency injection. То это сильно сократит стоимость.
Но если у вас очень нагруженное приложение и требование по перформансу очень высоки, то DDD может быть действительно не для вас.
Автор прав, идеально добиться состояние, когда сущность после создания всегда находится в валидном состоянии, т.е. инварианты всегда соблюдаются.
Есть давняя статья Грега Янга (создателя термина CQRS как паттерна построения приложений) — http://codebetter.com/gregyoung/2009/05/22/always-valid/
Основная идея там: «it is not that an object must always be valid for everything, there are lots of context based validations… Always valid means that you are not breaking your invariants.»
Т.е. есть контекстные проверки по которым сущность будет не валидна, но все инварианты должны выполняться.
Например, у вас вашего объекта Client есть поле email
По контекстной проверке (проверка на то, что имейл должен быть корпоративным либо принадлежать какому-то специфичному домену) объект может не проходить.
Но то, то что формат имейла правильный — это invariant который должен выполняться.
Ну, сам процесс создание объектов-сущностей не большая проблема. И даже большое кол-во зависимостей может быть не проблемой (хотя большое кол-во зависимостей это «smell» в коде, который намекает, что ваш объект берет на себя много обязанностей и вероятно нарушает принцип единой ответственности, что всегда плохо в ООП) если у вас есть Object Manager (Entity Manager/DI Container) который проинстанциирует все внешние зависимости сущности.
Но конкретно в вашем примере нельзя Client называть Enitity. У вас это классический Data Transfer Object, т.к. вы показали что он хранит только данные и аксессоры к этим данным. И никаких методов бизнесс логики
то, что валидация в двух местах это не страшно.
Валидация в контроллере может проверять по Read DB (читай кешу), и должна ответить на вопросы:
1. Может ли данная команда быть успешной
2. Правильно ли сформирована команда с учетом входных данных
Валидация Бизнес Логики, осуществляемая в хендлере команды — это валидация по Write DB, и эта валидация учитывает непосредственное состояние системы перед ее изменением.
— компонентный фреймворк общего использования
— e-commerce фремворк, который построент на нашем фреймворке (пункут 1).
Просто CMS Magento назвать нельзя, не смотря на то, что CMS в самой мадженто есть
Релизы 2.0 и 2.1 являются коммерческими релизами платформы, а не релизами компонентов. Они вполне могут быть несовместимы между собой. Хотя между 2.0 и 2.1 несовместимости были минимальны.
Здесь об этом можно почитать подробней
Такая основная идея связи между версиями платформы и версиями компонентов
И когда 2.1 релизилась Magento публиковала список обратно несовметимых измениний для 2.1
Стоки в Мадженто отдельная история, не зря в офисе весит такой девиз.
Из API интерфейса StockItemInterface знание о вебсайтах убрали. Идеально поля website_id не должно быть в таблице StockItem, т.к. StockItem это не что иное как сущность-связка продуктов к стокам, которое хранит кол-во товара на конкретном стоке. Опять же идеально было бы если бы такую связку мы могли задавать в каком-то скоупе, website только один из возможных скоупов. Пока поле website_id в таблице это рудимент, так как опять же пока еще Magento из коробки поддерживает только один сток. Но с точки зрения индексов сделали, чтобы комьюнити могло самостоятельно писать малти стоковые экстеншены.
Мадженто идет к тому, чтобы любые сущности были расширяемы дополнительными атрибутами. Не только перечисленные вами, а все, включая сущности добавленные сторонними разработчиками. Первый шаг был сделан к этому с добавлением Extension Attributes в Data API интерфейсы. Но пока это нельзя назвать полноценной заменой EAV, потому что программист обязан сам заниматься персистингом и ретривингом данных этого атрибута, что приносит замедление производительности. Поэтому корректное решение в данном случае было бы взять ответственность по сохранению и извлечению атрибута, а также эффективному хранению и фильтрации по нему на сторону Мадженты, а не стороннего программиста.
Это известный gap, не могу сказать когда именно он будет исправлен
Также в ближайшее время подобный ивент пройдет в Хорватии.
Идея простая — представители комьюнити фиксят открытые GitHub issue и вмете с представителями Core Magento Team обрабатывают фикс, ревьювят и вливают в Magento mainline.
Комьюнити вроде бы довольно такой инициативе.
По поводу других комьюнити инициатив также можно прочитать здесь.
Но основная — это то, что выделилась отдельная команда Community Engineering Team, которая занимается процессингом внешних Pull Request-ов. Чтобы максимально уменьшить время ожидания пул реквестов в очереди.
За успехами этой команды можно следить на открытой GitHub борде с PR-ами.
ну и собственно представити комьюнити уже сами начали ревьювить и процессить внешние пул реквесты.
Об этом в ближайшее время будет отдельный пост на Хабре.
Вы и руками пишете такую аброкадабру, когда есть конструкция IN?
Абсолютно нечитаемо и неэффективно, также как и конструкция вроде EXISTS.
Хотя судя по этому листингу Prestashop их код особо и не расчитан, чтобы его нормально кастомизировали и правили
Контракт сущности (entity) не должен состоять из getter/setter к данным из которых эта сущность состоит
Поэтому может просто имеет смысл выделить отдельную сущность — доменную модель. А DTO оставить как DTO. Сериализируемый объект, который всегда можно передать по сети.
у вас в квери сценарии будут какие-то недоинициализированные сущности, с нерабочими интерфейсамми, которые кидают эксепшены на вызовах определенных методов.
В этом и фишка CQRS — у вас две архитектуры, для чтения и записи. И масштабируете вы их тоже отдельно. Это не недостаток, а достоинство подхода. А вы хотите это нивелировать, пытаясь это уложить на одну кодобазу.
В CQRS подходе DDD у вас живет только в коммандах, квери должны быть очень упрощенными и быстрыми.
Как правило с отдельным индексом и без тяжелого ORMа
А по поводу вопросов дороговизны. Если ваши сущности иммутабельны, т.е. не изменяемы, то вы вполне можете их шарить по всему приложению, так как никто не сможет их поломать изменив глобальный стейт. И у вас есть некий Object Manager — глобальный контейнер в который кладутся уже созданные сущности и который отвечает за создание новых, которые требуются параметрами конструкторной dependency injection. То это сильно сократит стоимость.
Но если у вас очень нагруженное приложение и требование по перформансу очень высоки, то DDD может быть действительно не для вас.
Есть давняя статья Грега Янга (создателя термина CQRS как паттерна построения приложений) — http://codebetter.com/gregyoung/2009/05/22/always-valid/
Основная идея там: «it is not that an object must always be valid for everything, there are lots of context based validations… Always valid means that you are not breaking your invariants.»
Т.е. есть контекстные проверки по которым сущность будет не валидна, но все инварианты должны выполняться.
Например, у вас вашего объекта Client есть поле email
По контекстной проверке (проверка на то, что имейл должен быть корпоративным либо принадлежать какому-то специфичному домену) объект может не проходить.
Но то, то что формат имейла правильный — это invariant который должен выполняться.
Но конкретно в вашем примере нельзя Client называть Enitity. У вас это классический Data Transfer Object, т.к. вы показали что он хранит только данные и аксессоры к этим данным. И никаких методов бизнесс логики
Валидация в контроллере может проверять по Read DB (читай кешу), и должна ответить на вопросы:
1. Может ли данная команда быть успешной
2. Правильно ли сформирована команда с учетом входных данных
Валидация Бизнес Логики, осуществляемая в хендлере команды — это валидация по Write DB, и эта валидация учитывает непосредственное состояние системы перед ее изменением.
Таким образом мы получаем отказ при Command валидации в очень редких случаях.
Подробнее можно послушать здесь
https://channel9.msdn.com/Blogs/MichaelLehman/PP-Symposium-2010-The-Commmand-Query-Separation-Pattern-Chris-Tavares
Начиная с 15:00