In this article we are going to express about the module based architecture and MVVM architecture of Magento 2. You will learn the fundamentals of each of the 4 layers of Magento 2 architecture. Understanding layered software pattern is essential for understanding basic Magento product organization.
Magento’s module-based architecture description
Modules in Magento 2 are implemented by means of MVVM architecture.
MVVM is divided into 3 layers:
- Model. Just like in classic MVC, Model is the logic of data management and a description of the fundamental data, necessary for the operation of the application.
- View. View is a graphical interface, e.g. windows, buttons, etc. View is a subscriber to changes of the property values or commands provided by the View Model. In case a property changes in the View Model, it notifies all subscribers about this, and the View, in its turn, requests an updated property value from the View Model. If a user is manipulating an element of the interface, the View invokes the appropriate command provided by the View Model.
- View Model. The view model is an abstraction of the view exposing public properties and commands. It contains a Model that is converted to a View, and also contains the commands that the View can use to influence the Model.
According to the official documentation, Magento 2 architecture is split into 4 layers.
1.Presentation Layer.
Presentation Layer is the upper layer. It contains all the View elements (including layouts, blocks, templates, css, js) and controllers.
Presentation Layer usually calls service layer using service contracts. But, depending on the implementation, it may overlap with business logic.
2.Service layer.
Service layer is an interlayer between presentation layer and domain layer. It implements service contracts, which are defined using PHP interfaces. Service contracts allow to add or change business logic resource model using dependency injection file (di.xml). Service layer is also used for granting access to API (REST/SOAP or other modules).
Service interface is declared in/Api namespace of the module.
Data (entity) interface is declared in /Api/Data. Data entities are data structures passed to and returned from service interfaces.
3.Domain layer.
Domain layer is responsible for the business logic, which does not contain resource-specific or database-specific information. Domain layer can also include service contracts.
Each data model at the level of domain layer depends on the resource model, which is responsible for accessing the database.
4.Persistence layer.
Persistence layer describes resource model, which is responsible for extracting and modifying data in the database using CRUD requests.
Additional business logic capabilities are also implemented here, for example, data validation and database functions implementation.
The limitations of the module
Some modules may conflict with each other if the dependencies in module.xml (sequence) are incorrectly indicated.
Not all standard classes can be redefined using modules.
The interaction between different modules
Modules interact with each other using Dependency injection (di.xml) and layout files (/view/frontend/layout, /view/adminhtml/layout). They can also depend on other modules if they use their logic.
Side effects from the interaction between modules
If modules use Dependency injection, they can load in the wrong order or try to redefine the already redefined functionality of the module. To solve this problem, you should use sequence in module.xml.
If the modules use other modules’ logic and the module, whose logic is used, is disabled, dependencies will not be used and an error will occur when executing the code.
That’s it concerning Magento 2 module-based architecture, we hope you found it useful.
