Depending on your role and objectives for delving into Magento, there are various perspectives to consider regarding its architecture.
For instance, a developer aiming to craft new modules or customize existing ones would seek insights into the module’s architecture and its integration within the broader framework of Magento and other components.
On the other hand, a merchant aspiring to swiftly establish an online storefront would prefer to examine the assembly of components from a broader standpoint. They aim to grasp the components influencing the aesthetics, functionality, and user interaction elements.
What is an application architecture?
Application architecture refers to the methods and strategies employed in crafting and developing an application. It serves as a guide, offering a roadmap and recommended practices to ensure the creation of a properly organized and functional app.
What is the architecture of Magento?
In actuality, the Magento 2 request life cycle deviates from the standard MVC pattern and is more intricate. Here’s an overview of how interactions unfold:
Magento’s approach to managing requests?
Standard requests in Magento are directed through the pub/index.php file, serving as the entry point. This file orchestrates the loading of a bootstrap and subsequently initiates and executes the application. Following this, the front controller class navigates through all registered routers within the system to determine the appropriate routing destination. This routing decision can lead the request to controllers, resolvers, or API models.
How Magento manages the flow of data
Magento ensures that direct access to the database is avoided, relying instead on repositories, factories, and collections. These components serve as the means to manipulate entities, which are essentially represented as models. The actual database operations are exclusively carried out by the resource model. By utilizing a resource model, one can establish mappings between the properties of entities and their corresponding database structures.
The benefits of layered application design
- Separating business logic from presentation logic streamlines customization, allowing adjustments to the storefront’s appearance without impacting backend operations.
- Well-organized code facilitates extension developers in locating specific code segments reliably.
The architecture of Magento 2
Magento 2 employs a Model View ViewModel (MVVM) architecture, which enhances the separation between the Model and View layers, akin to the Model View Controller (MVC) pattern. Here’s a brief overview of MVVM:
-
Model: In MVVM, the Model serves as the data layer, defining the system’s business logic and representing the application’s state. Model objects handle data retrieval and storage in a database, applying rules to manipulate data that reflects the concepts managed by the application.
-
View: The View presents the graphical interface visible to users on the screen. It displays responses to user requests, structuring or formatting data in a specific layout. Views determine how data appears to users.
-
ViewModel: Acting as an intermediary between the Model and View layers, the ViewModel interacts with the Model to provide only necessary information to the View. It processes business logic, handles requests, manipulates data using the Model, and interacts with Views to produce the final output.
Layers in Magento
Magento 2’s architecture is structured into four distinct layers, each serving a specific purpose as outlined in the official documentation:
Presentation Layer
At the topmost level lies the presentation layer, which encompasses the code responsible for user interaction with Magento’s web interface. This layer houses controllers and View components such as layouts, templates, blocks, CSS, and JavaScript.
Interaction with the service layer, typically via service contracts, is common within the presentation layer. While primarily focused on user interaction, it may also encompass some business logic.
Users of the presentation layer include web users and system administrators.
Service Layer
Sitting between the presentation and domain layers, the service layer acts as a bridge facilitating communication between these two layers and handling resource-specific data.
Service contracts, defined through PHP interfaces, are implemented within this layer, allowing for the addition or modification of business logic without disrupting the system. Dependency injection configuration files (di.xml) facilitate this flexibility.
The service layer also provides access to APIs (such as REST or SOAP) and resides above the domain layer while lying below the presentation layer.
Domain Layer
Responsible for housing business logic, the domain layer remains devoid of database-specific or resource-specific details. Here, generic Magento data objects or models are defined, encapsulating the business logic pertaining to various operations on specific types of data, such as Customer objects.
To interact with the database via MySQL calls, each model within the domain layer is associated with a resource model.
Persistence Layer
At the bottommost level, the persistence layer revolves around the resource model, tasked with data extraction and modification within the database through CRUD (Create, Read, Update, Delete) operations. This involves SQL code within the resource model to fulfill these requests, along with additional implementations of business logic capabilities.
Final Words
In conclusion, Magento’s layered architecture offers distinct advantages for developers and merchants alike. By understanding its four layers, businesses can effectively manage business logic, presentation, and data flow to enhance their online storefronts.
Whether you’re crafting modules or focusing on user experience, Magento’s architecture provides a solid foundation for success in e-commerce.
