Understanding different layers of Magento module development
1. QuickRead
Magento’s product architecture at its highest level consists of the core product code plus optional modules. These optional modules will improve or override the basic product code.
If you are significantly customizing the basic Magento package, the production of the module will be your main focus. Modules organize a code that supports a specific task or function. The module will include a code to adjust the look-and-feel of your storefront as well as its basic actions.
Your modules work with the Magento product code core, which is organized into layers. Understanding layered software patterns is important for understanding Magento’s basic product organization.
Layered software is a common, widely-discussed concept in software development. There are several resources available for this topic, but consider consulting Pattern-Oriented Software Architecture for a general discussion.
Benefits of layered framework design
Layered framework architecture provides many benefits, but Magento users will appreciate:
- Stringent separation of business logic from presentation logic simplifies the process of customization. For example, you can change the appearance of your storefront without impacting any of the backend business logic.
- Clear code organization predictably points extension developers to the code location.
In this article, we will include a clear description of each of the four layers in Magento 2 and how they are used in the Magento 2 application.
Magento 2 Architecture can be divided into the following layers:
- Presentation layer
- Service layer
- Domain layer
- Persistence layer
2. Domain layer
The Magento Domain layer
The domain layer contains the business logic layer of the Magento module. Usually, it does not contain resource-specific or database-specific information. Its primary functions shall include:
Defining generic Magento data objects or templates containing business logic. This logic specifies the operations that can be performed on specific types of data, such as the Customer Entity. These models contain only generic details. Applications may also use SOAP or RESTful endpoints to request model data.
(Optionally) including the implementation, but not the description, of service contracts.
Models
Each domain-layer model includes a reference to a resource model that is used to retrieve data from the MySql call database. This resource model includes the logic of connecting to the underlying database, usually MySQL. A model needs a resource model only if the model data must be maintained.
Access to the domain layer
There are three primary ways to access the domain-layer code of the module:
Service contracts are the recommended way for one module to access the domain-level code of another module. This loosely coupled approach is the ideal way for most modules to reach another module.
You may call a module directly to another module. This tightly coupled approach is not recommended in most cases but is often inevitable.
The domain layer code in one module can also be plugged into another module by:
- event hooks
- plugins
- di.xml files (with an SPI contract)
Your strategy for calling another module’s domain-layer code is highly dependent on your system’s specific configuration and needs.
3. Persistence Layer
Magento uses an aggressive persistence record pattern technique. The model object in this framework includes a resource model that maps an object to one or more database rows. The resource model is responsible for the performance of functions such as:
Execute all CRUD (create, read, update, delete) requests. The resource model contains the SQL code to complete these requests.
Perform additional business logic. For example, a resource model may perform data validation, start processes before or after data is stored, or perform other database operations.
If you plan to return several items from a database query, you can introduce a special form of resource model known as a collection. The collection is a class that loads multiple models to an array-like structure based on a set of rules. It is similar to the SQL WHERE clause.
A simple resource model defines and interacts with a table.
However, some objects have a large number of attributes, or they may have a set of related objects with a varying number of attributes. In these instances, objects are constructed using the Entity-Attribute-Value (EAV) model.
Any model that uses an EAV resource has attributes distributed over a number of MySQL tables.
The Customer, Catalog, and Order resource models use EAV attributes.
XML Declarative Scheme
Magneto introduced Declarative XML Schemas with Magento 2.3. These are XML files that are used to specify the final state of the database. These files replace the PHP update scripts that were required to upgrade the module. These files make it possible to bypass progressive update scripts and jump straight to the final state of the database.
4. Presentation Layer
What is the Magento Presentation layer?
When you communicate with the Magento web interface, you interact with the presentation layer code. The presentation layer is the top layer of the four layers (presentation, service, domain, and persistence layers) defined in the Magento architecture.
The presentation layer includes both view elements (layouts, blocks, templates) and controllers that process commands to and from the user interface. The web user’s interaction with the product and its appearance is regulated by the presentation code. You can customize the user interface extensively by using HTML, CSS, and PHTML files to change the presentation layer elements. The presentation layer is basically a customization of HTML, CSS, JavaScript, Magento UI, PHTML files, and block files.
Who uses the Presentation layer?
Magento makes web service calls efficiently by loading only the dependent code that is needed for the specific type of user. The presentation layer code is interacted with by three types of Magento users:
Users communicate with the storefront, which displays Magento’s View model of data and allows them to interact with product UI elements to request data for viewing and manipulation. These users are in control of the frontend.
By adding themes or widgets to the frontend, system administrators may indirectly control the presentation layer while customizing a storefront.
Web API calls can be made via HTTP just like browser requests and can be made via AJAX calls from the user interface.
Components of the Presentation layer
One useful way to consider the components of the Magento presentation layer is to examine the themes of Magento. Magento themes coordinate both the visual component of your storefront and some aspects of product behavior.
Each theme resides in a specific directory and includes custom page layouts, templates, skins, and language files that function together to create a unique user experience.
See the Frontend Developer Guide for an extensive introduction to theme elements and an overview of how to expand and override the default Magento themes.
GraphQL
GraphQL is a data query language developed internally by Facebook in 2012 before being published publicly in 2015. Magento implements GraphQL to provide an alternative to the frontend web APIs for REST and SOAP.
GraphQL allows you to specify the structure of the data you need, and the server only returns the data you need. Each GraphQL-capable module contains a declarative schema that specifies the query syntax that the module supports, as well as the attributes that can be returned. If you run a REST call, such as GET/V1/products/:sku, on a simple product, the device can collect more than 100 lines of data. If all you need is the current price, the call returned considerably more information than you need. With GraphQL, a query against the same SKU could only return the price.
Progressive Web Applications
The Magento Progressive Web App (PWA) Studio project is a collection of developer tools that enable you to create, deploy and manage a PWA storefront at the top of Magento 2. PWA is a way to present Magento through a series of React JavaScript components. Using Magento as a headless backend, you can use the PWA components to build a mobile, user-friendly frontend.
Model view
Magento creates the HTML for a page that can be viewed from the view tree to the user.
View items fall into two major categories: blocks and containers.
Blocks can generate dynamic content and can contain named child view elements that are similar to arguments passed in. (The as attribute stores the names of the child view elements so that the parent block may refer to them.)
Containers hold a collection of children’s view components that are arranged in a specific order.
By instructing the view element tree to turn itself into HTML, the browser creates a product web page. Containers and blocks emit HTML that correctly encloses their children. Static HTML, Knockout JS files, and PHTML can all be used to create content for blocks.
How does Presentation code communicate with other layers?
Usually, presentation code refers to service contracts, particularly for a storefront. Presentation code, on the other hand, is often dependent on a particular implementation that allows the presentation code to call the domain layer directly. The Admin UI displays, for example, are often tied to a particular implementation and are not universally applicable.
To get information about the state of the program, the View layer calls code from the Model layer (for example, the price of a product). It usually uses service contracts to gain access to the Model.
Flow of the presentation layer
Web-users communicate with presentation layer components to choose behaviors that cause calls to the underlying layers. Components in the presentation layer make calls to the service layer, which sends requests to the domain layer.
5. Service Layer
What is a Service Layer, and how does it work?
The service layer connects the presentation layer to the domain layer, as well as resource-specific data. Service contracts, which are specified using PHP interfaces, are used to enforce this.
The service layer, in general, consists of the following components:
- Above the domain layer and below the presentation layer.
- Service contracts specify how the implementation will work.
- The REST/SOAP API application code is easily accessible (which also resides above the service contracts). No coding is necessary to connect service contracts to web service APIs.
- Provides a dependable API for other modules to use.
Who accesses the service layer?
All calls to your storefront from web service interfaces or users (that is, controller-initiated requests) are usually routed via the service layer. To call business logic, we strongly recommend using service contracts.
Easy SOAP and REST calls can be used by external applications to request business logic. You can expose the service layer’s PHP API and make it available to REST or SOAP web services using some basic XML or JSON. A web service can make a single API request and return an information-rich data structure once it is implemented.
Clients of service contracts include:
- Controllers’ (initiated by actions of users of the storefront)
- Web-based applications (SOAP and REST API calls)
- Other Magento modules are available through service contracts.
Service Contract Anatomy
The module service contract is specified by a collection of interfaces in the/Api module directory.
This directory includes the following:
Service interfaces in the/Api namespace of the module (Catalog API).
Data (or entity) interfaces in the directory of Api/Data (Catalog API/Data[]). Data entities* are data structures that are transferred to and returned from service interfaces.
Files in the data directory include get() and set() methods for inputs in the entity table and extension attributes.
Typically, service contracts have three distinct interface types:
- Interfaces for repository
- Interface management
- Interface Metadata
However, there is no requirement that service contracts comply with all three trends.
Benefits of service contracts
Service contracts allow you to implement a new customer extension that incorporates or modifies business logic resource models without breaking the system.
This is achieved by using the feature in the dependency injection configuration file (di.xml) of the custom module.
The di.xml file defines which PHP class to use for the
Magento\Customer\Api\CustomerRepositoryInterface interface.
A different module may modify this interface file by specifying a different class name. However, if the client code uses the interface description only, there is no need to modify the class.
Skip to content
