There are four architectural tiers in Magento: the domain layer, the persistence layer, the presentation layer, and the service layer. Thoroughly understanding the Magento architecture tiers or layers can help developers better customize the platform to their clients’ needs.
Magento 2 architecture tiers (layers)
Domain layer
Magento’s domain layer holds the business logic belonging to a Magento module. Typically, it doesn’t contain any database- or resource-specific information and only defines generic data objects or models containing the business logic.
The logic contained in the domain layer defines the operations performed on various types of data like a customer object. Optionally, they may also include implementing service contracts, although this isn’t necessarily defined as their role.
A module’s domain-layer code can be accessed in one of the following three ways:
- By using service contracts to communicate with the layer and passing data using strongly typed objects. This is the most optimal method of communicating with the domain layer and one that is also recommended for Magento.
- By directly calling one module from the other. This is sometimes unavoidable; however, it is generally not recommended for most situations.
- By allowing the domain layer code in one module to plug into another using either event hooks, plugins, or di.xml files.
Although using service contracts is the recommended method, an individual store’s configuration and needs usually define which of the three methods is used to access a module’s domain layer code.
Persistence layer
Magento employs the active record pattern strategy for persistence. This pattern is used to access data stored inside a database by mapping an object to one or more rows in the database.
This data is mapped by resource models responsible for performing actions such as creating, reading, updating, and deleting database requests using SQL code stored inside them. They also perform other business logic such as data validation, starting processes before or after saving data, and some database operations.
Usually, a simple resource model will only define and interact with a single database table. When you wish to return multiple items from a database query, you can use a ‘collection’, that is a class capable of holding numerous models in an array-like structure.
Occasionally, some objects such as product or customer data may contain many attributes or have objects with varying numbers of attributes. In such cases, the objects can be constructed using the Entity-Attribute-Value model that spreads attributes over many MySQL tables. In Magento, only the Catalog, Customer, and Order resource models use EAV attributes.
Presentation layer
The top-most layer of the Magento architecture is called the presentation layer. This is the layer that end users usually interact with in the form of the web interface. It comprises both view elements such as layouts, blocks, templates, and controllers responsible for processing commands in the user interface.
The presentation layer code controls the product’s frontend appearance and its user interactions. It can be fully customized using a mix of HTML, CSS, and PHTML files to alter the elements inside the presentation layer.
This layer is generally used by web users when interacting with a storefront, system admins when customizing a storefront using themes or widgets, and by web API calls made through HTTP requests and AJAX calls from the user interface.
The best way to understand the Magento presentation layer is by examining Magento themes and analyzing how the themes organize the design and functionality of a storefront. Magento themes reside in unique directories containing a mix of customized page layouts, templates, skins, and language files that work in unison to create an appealing end-user experience.
Service layer
The service layer in Magento is responsible for communicating between the top-most presentation layer and the domain layer. It uses service contracts defined using PHP interfaces to determine code behavior, provides easy access to the API framework in Magento, and provides a stable API that other modules can call into.
Any calls made by users working with the storefront or by web service interfaces are generally routed through the service layer. External services can access the service layer and get information-rich data structure using a single API call. Using an XML or JSON file, developers can provide external applications with access to the service layers PHP APLI to make requests with SOAP and REST calls.
Layered software architecture is a popular and frequently used principle in software development as its use in application design offers numerous advantages.
In Magento, the layered architecture provides a clear separation between the backend and the frontend code. This enables the alteration of the frontend design without affecting the backend business logic.