Hey, Amasty blog readers!
We continue working on a list of answer posts dedicated to the Magento 2 certification and have already covered the first topic from the study guide.
This week we’ve asked our team developer Vitaly to describe Magento 2 module-based architecture and clue us in on the module limitations and interaction.
Magento 2 module-based architecture [brief overview]
As is known, modules and themes in Magento 2 are used as elements of customization. Where modules give different features and properties to a site, and themes affect the appearance.
Both modules and themes have their own life cycle, which allows you to install, disable and delete the elements.
What does that give you?
The Magento modularity approach makes the code clearer. It allows you to simplify the development process and the process of identifying and correcting defects.
What is the overall aim of any Magento module?
Each module is developed to provide specific Magento features, introduce new features or extend the functionality of other modules.
According to Magento developers,
Any module forms an independent logical group consisting of blocks, controllers, helpers, and models (php and xml files). Thus, the modularity approach assumes that each module has its own unique properties and features. The fact simplifies the development and improves the quality of the framework Magento 2 architecture.
Modules are usually located in Magento 2 vendor directory. The directory has the next format: vendor / <vendor> / <type> – <module-mame> where <type> can be assigned to one of the values below:
- module – for modules (module-customer-import-export)
- theme – for interfaces and administrators (theme-frontend-luma or theme-adminhtml-backend)
- language – for language packs (language de_de)
All the new modules should be created in the / app / code directory or in the vendor directory when using Composer.
E.g.: You can create a customer module (Example CompanyName) in the path / app / code / CompanyName / Example
Despite the executable files (database files and frontend files), the directory contains the module configurations, as well as the etc / module.xml file. This file includes the information about the name and version of the module and all the module dependencies.
Each module should be named and declared in the module.xml file, which can be found here: / app / code / <Vendor> / <ModuleName> / etc /. When giving a name to a module you need to take into account the Namespace_Module scheme. Where the “Namespace” is the name of the module developer (vendor) and “Module” is the name given to the extension by the developer (vendor). You need to describe the full name and dependencies:
Module dependencies and limitations
Minimization of software dependencies is a basic principle of Magento 2 dependency concept. Modules are normally designed to be loosely interrelated with others. Thus, each module is responsible for a unique feature. In this case, modules perform their tasks with little or no knowledge of others. In this, disabling or removing one module should not lead to the disconnection or removal of other modules. However, do not forget that all dependencies must be properly declared.
A module can have the following relations with others:
- uses: module A uses module B;
- reacts to: module A reacts to module B if its behavior is triggered by an event in module B (without the knowledge of module B about module A);
- customizes: module A customizes module B in case it changes the behavior of module B;
- implements: module A implements module B if it implements any behavior part defined in module B;
- replaces: module A replaces module B if it provides its own API version, which is opened and implemented by module B.
All modules are dependent on a set of core logic: PHP code, libraries, and the basic functions. The components are inherited by the modules.
To manage module dependencies you need to know these 3 main steps:
- name and declare the module in the module.xml file;
- declare the module dependencies in the composer.json file of the module;
- decide on the load order of config and css. files in the module.xml file (if needed).
E.g.: Module “Magento_Email” declares a dependency on module “Magento_Cms”. So, in the module.xml file of the “Magento_Email” module the module “Magento_Cms” will be given in the <sequence> list. Thus, “Magento_Cms” files are loaded before “Magento_Email” files. Besides, you need to declare a dependency on module “Magento_Cms” in the composer.json file of the “Magento_Email” module:
All Magento 2 dependencies are formed by admin in the composer.json file of each module:
Types of module dependency
In Magento 2 there are 2 types of module dependencies: (1) hard and (2) soft dependencies.
Modules with a hard dependency can’t function without the modules they depend on. Where modules with soft dependency can function independently.
If your module uses code from another one, you should clearly inject the Magento 2 dependency.
How to load dependencies?
The <sequence> list is an optional element and is applied only in case other modules are involved and you need to indicate files load dependencies. The list isn’t used for other types of components.
E.g.: Basic syntax:
Magento modules installation order
Firstly, install the module that serves as a dependency for another one; secondly, install the module dependent on it.
Avoid the following dependencies in Magento 2:
- circular (both direct and indirect)
Main module limitations
- The more dependencies a module has, the more difficult it is for you to transfer it to another project;
- You need to maintain a strict installation order;
- Multiple module dependencies violate the principle of Magento modularity;
- It complicates modules debugging and the logic of such modules.
We hope it was helpful! Drop us a line if you still have questions on the topic.
P.S. Don’t forget to stay tuned and check our next posts in preparation for Magento 2 certification exam!