Magento 2 Architecture

Let’s get familiar with Magento 2 architecture and terminology.

Magento has a very specific architecture, designed with the intent of making the source code as modularized and extensible as possible (this mostly refers to dependency injection and the use of design patterns such as the Model-View-Controller (MVC), which will be more thoroughly covered in the sections below). 

This makes it easy to adopt, and more importantly,  swiftly customizable for the specific needs of each project. Moreover, new functionalities, which are often incorporated in the form of extensions, work as standalone units (here it’s important to emphasize that although extensions are usually separate components, they are not completely independent of the core system). This supports the ever-changing eCommerce trends and underpins a variety of business strategies and approaches. 

If you are substantially customizing the base of your Adobe Commerce or Magento Open Source product, module development will most probably be your top priority. Code is organized in modules that support a particular task or feature. A module’s code can provide some additional functionalities or modify the existing ones and affect how your store looks and functions. 

Other approaches to Magento base product customization include theme development, integration with APIs, and customization through the use of configuration options.

The Model View ViewModel (MVVM) Architecture Pattern

Magento 2 has a Model View ViewModel (MVVM) architecture pattern. This MVVM architecture provides a much more robust separation between the Model and View layer, as it is closely related to the Model View Controller (MVC). 

Let’s quickly explain the logic behind MVVC:  

• The Model holds the business logic of the application and depends on an associated class (the ResourceModel) for database access. Models rely on service contracts to expose their functionality to the other layers of the application.
• The View is the structure and layout of what a user sees on a screen – the actual HTML. This is achieved in the PHTML files distributed with modules. PHTML files are associated with each ViewModel in the Layout XML files, which would be referred to as binders in the MVVM dialect. The layout files may also assign JavaScript files to be used on the final page.
• The ViewModel interacts with the Model layer, exposing only the necessary information to the View layer. In Magento 2, this is handled by the module’s Block classes. Note that this was usually a part of the Controller role of an MVC system. On MVVM, the controller is only responsible for handling the user flow, meaning that it receives requests and either tells the system to render a view or redirects the user to another route.

The modules function with the core product code, and if you want to understand the basics of Adobe Commerce and Magento Open Source product organization, firm grapes of layered software patterns are essential.

Magento 2 Layers

Magento 2 consists of 4 layers:  

1) Presentation Layer

The presentation layer is the uppermost layer of Magento 2 architecture. When you interact with Magento’s web interface, you are interacting with the presentation layer code. This layer contains all controllers and Views elements such as – layouts, templates, blocks, css.js, etc, and is mostly used by web users and system administrators.

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 by 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 which operation can be performed on particular types of data, such as Customer objects.

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

This robust platform uses the active record pattern for saving. In Magento, the model object contains a resource model that compares the object with one or more database records. The resource model is responsible for performing functions such as:

• Executing all CRUD requests – the resource model contains the SQL code for executing these queries
• Performing additional business logic (for example, a resource model can perform data validation, run processes before or after saving data, or perform other operations on the database)

If you expect to return multiple items from a database query, you must implement a special type of Resource model, known as collection. Collection is a class that loads several models into a structure similar to an array, based on a set of rules.

I hope that this gives you a wider image of Magento 2 architecture and how this eCommerce platform accesses and manipulates data.