Understanding Magento 2’s Architecture: A Simple Yet Complete Guide

Every e-commerce platform’s underlying architecture assists in enabling the online store to function properly, offers flexibility to adapt to changing business needs, improved performance, enhanced security, and many other advantages.

However, if you are a developer or a Magento merchant it’s important that you have a basic understanding of the architecture of the e-commerce platform you are working on or have a store to offer products to your customers.

Your perspective on Magento 2 architecture will vary based on your role and objectives.

For instance, a developer aiming to create or customize modules must delve into the architecture of individual modules and understand how they integrate with the broader Magento 2 framework and its components.

On the other hand, a merchant focused on quickly building an online storefront will approach the architecture differently.

They’ll prioritize understanding the components that shape the storefront’s appearance, functionality, and user experience, focusing on aspects like design, interaction, and usability at a higher level.

Each role requires a tailored approach to learning Magento 2 architecture to meet specific needs effectively.

What is Magento 2’s Architecture?

Magento 2’s architecture is designed to ensure its source code is both versatile and easy to understand. This approach emphasises flexibility, allowing developers to customize and adapt it to meet specific project requirements.

The platform organizes its functionalities into modules, each capable of operating independently.

Magento 2 utilizes the Model–view–viewmodel (MVVM) architecture, which enhances the separation between the data layer and the user interface.

While closely related to the Model-view-controller (MVC) pattern, MVVM provides a more distinct division between the model and the visual presentation layer.

Understanding MVVM in Magento 2

Model

The model in MVVM is responsible for managing data and implementing the application’s core business logic.

It interacts with the database using a Resource Model and processes data requests. Similar to MVC, the model acts upon input received from the view.

View

The view represents the graphical interface that users interact with. It formats and displays data, responding to user actions and reflecting any changes in the ViewModel.

Essentially, the view determines how data appears on the screen and subscribes to updates from the ViewModel’s properties.

ViewModel

The ViewModel serves as a bridge between the model and the view, delivering only the necessary data to the visual layer. In Magento 2,

Block Classes handle this functionality. Unlike traditional MVC controllers, the ViewModel manages user flow by processing requests, determining the appropriate view to display, or redirecting users as needed.

Overview of Magento 2 Architectural Layers

The Adobe Commerce and Magento 2 framework consists of core product code and optional modules that enhance or replace basic functionalities.

For extensive customizations, module development is key. Modules support specific tasks or features, including altering the storefront’s appearance or behaviour.

These modules integrate with the core product code, which is organized into layered software architecture. Understanding this layered approach is crucial for working effectively with Adobe Commerce and Magento.

Suggested Reading: Top Features of the Latest Magento Upgrade for Ecommerce Success

Domain Layer Overview

The domain layer in Adobe Commerce and Magento 2 architecture is responsible for handling a module’s business logic without including database-specific or resource-specific details.

It defines generic data objects, or models, which dictate the operations that can be performed on certain types of data, such as a Customer object.

These models hold generic information and can expose data through SOAP or RESTful endpoints.

Optionally, the domain layer may include service contract implementations but does not define them.

To access domain-layer code:

1. Service Contracts: Recommended for loosely coupled module interaction.
2. Direct Calls: Not ideal, but may be necessary in some cases.
3. Integration: Achieved via event hooks, plugins, or di.xml files with SPI contracts.

The method chosen depends on your system’s requirements and configuration, with service contracts being the optimal approach for modularity and scalability.

Persistence Layer Overview

The persistence layer in Adobe Commerce and Magento design architecture uses an active record pattern to map models to database tables.

Resource models within the layer handle CRUD operations (create, read, update, delete) and additional business logic like validation or pre-/post-save processes.

When querying multiple rows, collections load models into array-like structures, mimicking SQL WHERE clauses.

Objects with extensive or dynamic attributes, such as Customers, Catalogs, and Orders, use Entity-Attribute-Value (EAV) models.

These spread attributes across multiple tables, enabling flexibility. For simpler objects, resource models interact directly with a single database table.

With version 2.3, Magento introduced Declarative XML Schemas to streamline database upgrades. These schemas specify the database’s final state, eliminating the need for incremental PHP scripts, thus simplifying module updates and ensuring consistency across development environments.

Presentation Layer Overview

The presentation layer in Adobe Commerce and Magento architecture is the interface users interact with when accessing the platform.

It sits atop the four-layer architecture (presentation, service, domain, persistence) and includes view components like layouts, blocks, templates, and controllers, which manage user commands and interactions.

This layer controls the appearance and functionality of the user interface, offering extensive customization through HTML, CSS, JavaScript, PHTML, and block files.

Users of the Presentation Layer

1. Web Users: Interact with the storefront’s UI to view or manipulate data in the frontend area.
2. Administrators: Indirectly modify the presentation layer by adding themes or widgets.
3. Web API Calls: Access UI elements through HTTP requests, including AJAX.

The presentation layer supports seamless interaction and customization, ensuring flexibility in design and functionality.

Service Layer Overview

The service layer connects the presentation layer with the domain and persistence layers, acting as a bridge.

It primarily uses service contracts defined as PHP interfaces to standardize behavior.

Functions of the Service Layer

• Bridges the presentation and domain layers.
• Houses service contracts to define interactions.
• Simplifies access to SOAP/REST APIs without additional coding.
• Provides a consistent API for other modules.

Accessing the Service Layer

• Web Users: Requests initiated by storefront controllers route through this layer.
• Web Services: External systems use SOAP or REST calls to interact with the business logic.
• Modules: Other modules use service contracts to access functionality.

This layer ensures stability and scalability, enabling smooth integration with APIs and other modules.

Read More: Essential Steps for Setting Up a Magento 2 Local Development Environment

Over To You

Magento 2’s architecture is a thoughtfully designed framework that caters to both developers and merchants, offering flexibility and scalability for diverse use cases.

Developers benefit from its modular structure, MVVM architecture, and layered approach, which streamline customizations and integrations.

Merchants, on the other hand, can leverage its customizable presentation layer to craft engaging and functional storefronts.

By understanding its core components—domain, persistence, service, and presentation layers—users can maximize Magento 2’s potential, whether by creating robust modules or enhancing user experiences.

With a solid grasp of its architecture, Magento 2 has become a powerful tool for building dynamic and scalable eCommerce solutions.