Architecture of Magento 2

In this topic, we are going to discuss the architecture of Magento 2. Magento 2 has a totally different architecture than Magento 1. Its architecture is designed with the objective of making the source code as an extensive and modularized as possible. The main purpose of this approach is to allow it to be easily adapted and customized according to the need of the project. Every business logic and functionality is designed in the form of modules. So, every module can work as a standalone unit.

Magento 2 has a Model View ViewModel (MVVM) architecture. This MVVM architecture provides much more robust separation between the Model and View layer, as it is closely related to the Model View Controller (MVC). The brief description of MVVC is given below:

Model: It holds the business logic of the application, and depends on an associated class - Resource Model for database access. Similar to the MVC, it is the logic of data management and description of the fundamental data which is necessary for the operation of the application. The model responds to the request coming from the view.

View: The view is a graphical interface that the users see on the screen. It is responsible for displaying the respond for the user request. The view is a structure or a layout, which represents the data in a particular format. Views specify that "how your data looks like". It is a subscriber for the changes of the property values or commands provided by the ViewModel.

ViewModel: The ViewModel interacts with the Model layer and exposes only necessary information to the View layer. This is handled by module's Block classes in Magento 2. An important thing to notice that this was usually part of the Controller role of an MVC system. In MVVM, the Controller is only responsible for handling the user flow means it receives requests and either tell the system to render a view or to redirect the user to another route.

It contains a Model which is converted to a View and also contains the commands that can be used to affect the Model. The ViewModel is basically an abstraction of the view exposing public properties and commands.

Magento 2 is split into four layers, according to the official documentation.

• Presentation Layer
• Service Layer
• Domain Layer
• Persistence Layer

The detailed description of Magento 2's layer architecture is given below.

1) Presentation Layer

The presentation layer is the uppermost layer of Magento 2 architecture. When we interact with the web interface of Magento, that time, we are interacting with the presentation layer code. It contains all controllers and View elements such as - layouts, templates, block, and css.js, etc. The presentation layer calls the service layer using service contracts, usually. It can overlap business logic.

Web users, system administrators, are the user of the presentation layer

2) Service Layer

The service layer is the middle layer among the presentation layer and domain layer. It provides a bridge between the presentation and domain layer and resource-specific data. The service layer implements service contracts, which are defined using the PHP interface. These service contracts allow us to add or change the business logic resource model without breaking the system. This is done using the dependency injection configuration file (di.xml).

The service layer grants access to API (REST/SOAP or other modules). It resides above the domain layer and below the presentation layer.

3) Domain Layer

The domain layer is responsible for business logic. It does not contain database-specific or resource-specific information. The domain layer defines the generic Magento data objects or models which contain business logic. This logic describes that which operation can be performed on the particular types of data, such as Customer object.

To retrieve the data from the database with the MySQL calls, each domain-layer model has a reference to a resource model.

4) Persistence Layer

It describes the resource model, which is responsible for data extraction and modification in the database using the CRUD (Create, Read, Update, and DELETE) requests. For completing these requests, the resource model contains the SQL code. Additional business logic capabilities are also implemented.

For example - database functions implementation and data validation.