1.1 Опишіть модульну архітектуру Magento

---

Огляд
registration.php
etc/module.xml
Опишіть обмеження модулю
Як модулі взаємодіють один з одним
Які побічні ефекти можуть виникати в результаті цієї взаємодії?

Огляд

Модульна архітектура Magento 2 влаштована таким чином, що всі файли модуля розташовані в одній теці. Це полегшує вивчення функціональності модуля.

Модулі розташовані в двох місцях:

• app/code/CompanyName/ModuleName
• vendor/vendor-name/module-name

У Magento 2 модулі можуть бути встановлені за допомогою Composer. Це дозволяє зробити процес оновлення та відслідковування версійності модуля простішим. Модулі встановлені за допомогою composer розташовані в теці /vendor. Будь які файли в цій теці є “недоторканними” (не редагуються напряму), так як ці файли будуть видалені при встановленні нової версії модуля. Встановлення модулів за допомогою Composer зменшує навантаження на розробника, оскільки більше не потрібно відслідковувати версії модулів. За вас це робить Composer.

У більшості випадків, модулі які ви будете розробляти, будуть зберігатися в теці app/code/CompanyName. Цей простір імен (namespace) використовується для розробки. Кастомні модулі будуть безпосередьно розташовані у цій теці.

Наприклад:

Мінімальний набір файлів для запуску модуля:

• registration.php
• etc/module.xml

registration.php

Цей файл включено в автозавантажувач Composer (app/etc/NonComposerComponentRegistration.php).

Це додає модуль (компонент) у статичний перелік компонентів у Magento\Framework\Component\ComponentRegistrar. Коли перелік буде сформовано, Magento буде шукати файл etc/module.xml

Наприклад:

etc/module.xml

Цей файл визначає версію налаштування (setup_version) та послідовність завантаження модулю. Версія налаштування також доступна у Setup класах, щоб визначити, які дії по оновленню повинні відбутися.

Послідовність (sequence) сповіщає Magento (vendor/magento/framework/Module/ModuleList/Loader.php) у якому порядку завантажувати модулі. Послідовність дотримується тільки тоді, коли модуль встановлено у системі. Перелік модулів та порядок їх завантаження зберігається у app/etc/config.php.

Послідованість корисна для подій (events), плагінів (plugins), преференсів (preferences) та леяутів (layouts). Спостерігачі подій (Observers) ніколи не повинні залежати від порядку їх виклику. Якщо ви зміните леяут (layout) іншого модуля і ваш модуль буде ініціалізовано першим, інший модуль перезапише ваші налаштування.

Наприклад:

Опишіть обмеження модулю

Модулі Magento 2 повинні містити весь код всередині теки модулю (тобто app/code/CompanyName/ModuleName). Всі налаштування та кастомізації виконуються всередині цієї теки. Якщо модуль вимкнено, він не працює. Майте на увазі, шо відключення модулю не призводить до автоматичного видалення його таблиць або записів в базі даних.

Якщо у вас виникли проблеми з включенням модуля, перевірте:

• Чи присутні необхідні файли (дивись вище).
• Чи увімкнено модуль (bin/magento module:enable CompanyName_ModuleName).

Як модулі взаємодіють один з одним?

Magento 2 надає значно покращену систему міжмодульної взаємодії. Magento 2 відповідає PSR-4. Цей стандарт описує що шлях до простору імен буде відповідати шляху файла до класу.

Хоча стандарт PSR-0 застарів, Composer все ще використовує цю ідею для допомоги у автозавантаженні класів. /composer.json (кореневої теки) повинен містити в собі вузол psr-0. Всередині нього буде значення app/code. Це має той же ефект що і додавання каталогу для пошуку в PHP.

Magento 2 не містить в собі класу “бог” Mage, як це було в Magento 1. Magento 2 спирається на сервісні контракти (service contracts) та інʼєкції залежностей (dependency injection), щоб визначити які класи використовувати. Більш детально ми це обговоримо у розділі “Інʼєкції залежностей” (Dependency Injection).

Сервісні контракти розташовані у теці app/code/CompanyName/ModuleName/Api. Представлення даних у теці app/code/CompanyName/ModuleName/Api/Data.

При створенні модулів які залежать від інших модулів, по можливості, використовуйте інтерфейси (interfaces) як це реалізовано у сервісних контрактах (service contracts). Таким чином, ваш модуль працює з чистою схемою, і не має значення, який клас чи модуль виконує цю схему.

Які побічні ефекти можуть виникати в результаті цієї взаємодії?

Кожний раз, коли ви працюєте з системою, в якій, будь-який встановлений модуль може розширювати функціональність ядра, є ризик отримати збої у роботі.

Якщо ви дотримуєтесь кращих практик і принципів розробки модулів Magento 2, наслідки дуже обмежені. Якщо ви порушуєте рекомендації - виникають помилки.

Як ми знаємо модулі інших розробників можуть змінювати різні речі в системі. Наприклад, ви встановлюєте модуль який вносить величезні зміни для продукту. Ці зміни настільки значні що розробник пише повністью новий клас для представлення моделі продукту. Цей клас було написано для сервісних контрактів які Magento визначає для продукту:

namespace CompanyName\ModuleName\Model

use Magento\Framework\DataObject\IdentityInterface; 
use Magento\Framework\Pricing\SaleableInterface; 
use Magento\Catalog\Api\Data\ProductInterface;

class Product implements IdentityInterface, SaleableInterface, ProductInterface
{
    // ...
}

Але, що якщо наш кастомний продуктовий код використовує метод, який визначено тільки в Magento\Catalog\Model\Product? Ви (або ваш клієнт на сайті) може отримати PHP Fatal Error при спробі викликати метод, якого не існує в іншому класі. Ця гнучкість неймовірна, але використовувати її потрібно з великою відповідальністю.

При роботі з класами Magento які використовують сервісні контракти (містять теки Api/ та Api/Data), використовуйте інтерфейси замість конкретних класів які реалізують (implements) сервісні контракти. Якщо вам необхідно явно використовувати клас, визначений у Magento (Magento\Catalog\Model\Product) зробіть залежність явною, покладаючись на конкретну реалізацію замість інтерфейсу сервісного контракту (service contract).