group: architecture-guide

title: Architectural basics overview

menu_title: Architectural basics

Magento incorporates the core architectural principles of object-oriented, PHP-based applications. Comprehensive discussions of these general principles exist both on-line and in printed form.

The following discussion focuses on how these topics apply directly to Magento:

* Magento technology stack

* Magento View Model

* Extensibility

* Modularity

* Event-driven architecture

* Security

[Architectural diagrams]({{page.baseurl}}/architecture/archi_perspectives/arch_diagrams.html)

[Technology stack]({{page.baseurl}}/architecture/tech-stack.html)

[Stack basics]({{page.baseurl}}/architecture/tech-stack.html)

[Versioning]({{page.baseurl}}/extension-dev-guide/versioning/)

group: architecture-guide

title: Architectural layers overview

menu_title: Architectural layers

At its highest level, Magento's product architecture consists of the core product code plus optional *modules*. These optional modules enhance or replace the basic product code.

If you are substantially customizing the basic Magento product, [module](https://glossary.magento.com/module) development will be your central focus. Modules organize code that supports a particular task or feature. A module can include code to change the look-and-feel of your [storefront](https://glossary.magento.com/storefront) as well as its fundamental behavior.

Your modules function with the core Magento product code, which is organized into layers. Understanding layered software pattern is essential for understanding basic Magento product organization.

Layered software is a popular, widely discussed principle in software development. Many resources exist for this topic, but consider consulting Pattern-Oriented Software Architecture for a general discussion.

Layered application design offers many advantages, but users of Magento will appreciate:

* Stringent separation of business logic from presentation logic simplifies the customization process. For example, you can alter your storefront appearance without affecting any of the [backend](https://glossary.magento.com/backend) business logic.

* Clear organization of code predictably points [extension](https://glossary.magento.com/extension) developers to code location.

[Architectural diagrams]({{page.baseurl}}/architecture/archi_perspectives/arch_diagrams.html)

[Presentation layer]({{page.baseurl}}/architecture/archi_perspectives/present_layer.html)

[Service layer]({{page.baseurl}}/architecture/archi_perspectives/service_layer.html)

[Domain layer]({{page.baseurl}}/architecture/archi_perspectives/domain_layer.html)

[Persistence layer]({{page.baseurl}}/architecture/archi_perspectives/persist_layer.html)

group: architecture-guide

title: Architectural diagrams

menu_title: Architectural diagrams

Depending upon your role and purpose for learning more about Magento, there are several different ways to view the Magento architecture. For example, a developer who wants to create new modules or perhaps customize an existing [module](https://glossary.magento.com/module) will want to understand the architecture of a module itself, and how it fits into the larger view, with the Magento framework and other components. However, a merchant who wants to quickly build an online storefront wants to view the collection of components from a higher level, and understand the components that impact the look, feel, and user interaction components.

The following diagram illustrates the components and shows the "layers" or tiers in Magento.

* [Architecture layers overview]({{page.baseurl}}/architecture/archi_perspectives/ALayers_intro.html)

group: architecture-guide

title: Magento Components

menu_title: Components

Magento has several core components that are used to build custom websites, applications, and integrated systems. When you change the appearance or behavior of your Magento store, you are inevitably changing one or more of these **core Magento components**, which include **modules**, **themes**, and **language packages**. Together, these core components determine much of server-side and [storefront](https://glossary.magento.com/storefront) (frontend) appearance and behavior.

{:.bs-callout .bs-callout-tip}

Throughout the Magento documentation set, we also use the term *component* in its generic sense to mean element or part. However, the term **Magento component** explicitly refers to either a module, theme, or [language package](https://glossary.magento.com/language-package).

For more information about individual Magento components, see:

* [Modules]({{page.baseurl}}/architecture/archi_perspectives/components/modules/mod_intro.html)

* [Themes]({{page.baseurl}}/frontend-dev-guide/themes/theme-overview.html)

* [Language packages]({{page.baseurl}}/frontend-dev-guide/translations/xlate.html#m2devgde-xlate-languagepack)

group: architecture-guide

title: Modules and areas

menu_title: Modules and areas

An *area* is a logical component that organizes code for optimized request processing. Magento uses areas to streamline web service calls by loading only the dependent code for the specified area. Each of the default areas defined by Magento can contain completely different code on how to process URLs and requests.

For example, if you are invoking a REST web service call, rather than load all the code related to generating user [HTML](https://glossary.magento.com/html) pages, you can specify a separate area that loads code whose scope is limited to answering REST calls.

Magento is organized into these main areas:

* **Magento Admin** (`adminhtml`): entry point for this area is `index.php` or `pub/index.php`. The [Admin](https://glossary.magento.com/admin) panel area includes the code needed for store management. The /app/design/adminhtml directory contains all the code for components you'll see while working in the Admin panel.

* **Storefront** (`frontend`): entry point for this area is `index.php` or `pub/index.php`. The storefront (or `frontend`) contains template and [layout](https://glossary.magento.com/layout) files that define the appearance of your [storefront](https://glossary.magento.com/storefront).

* **Basic** (`base`): used as a fallback for files absent in `adminhtml` and `frontend` areas.

* **Cron** (`crontab`): In `cron.php`, the [`\Magento\Framework\App\Cron`]({{ site.mage2bloburl }}/{{ page.guide_version }}/lib/internal/Magento/Framework/App/Cron.php#L68-L70){:target="_blank"} class always loads the 'crontab' area.

You can also send requests to Magento using the SOAP and REST APIs. These two areas

* **Web API REST** (`webapi_rest`): entry point for this area is `index.php` or `pub/index.php`. The REST area has a front controller that understands how to do [URL](https://glossary.magento.com/url) lookups for REST-based URLs.

* **Web API SOAP** (`webapi_soap`): entry point for this area is `index.php` or `pub/index.php`.

Modules define which resources are visible and accessible in an area, as well as an area's behavior. The same [module](https://glossary.magento.com/module) can influence several areas. For instance, the RMA module is represented partly in the `adminhtml` area and partly in the `frontend` area.

If your [extension](https://glossary.magento.com/extension) works in several different areas, ensure it has separate behavior and view components for each area.

Each area declares itself within a module. All resources specific for an area are located within the same module as well.

You can enable or disable an area within a module. If this module is enabled, it injects an area's routers into the general application's routing process. If this module is disabled, Magento will not load an area's routers and, as a result, an area's resources and specific functionality are not available.

* Modules should not depend on other modules' areas.

* Disabling an area does not result in disabling the modules related to it.

* Areas are registered in the [Dependency Injection](https://glossary.magento.com/dependency-injection) framework `di.xml` file.

Magento processes a URL request by first stripping off the base URL. The first path segment of the remaining URL identifies the request area.

After the area name, the URI segment specifies the *frontname*. When an HTTP request arrives, Magento extracts the handle from the URL and interprets it as follows: `[frontName]/[controller folder]/[controller class]` where `frontName` is a value defined in the module. For example, in `catalog/product/view`, `catalog` is the name of the module used, `product` is the controller folder, and `view` is the controller class. For deeper directory structures, the controller folders are separated with `_` (for example, `catalog/product_compare/add` for `Magento/Catalog/Controller/Product/Compare/Add.php`).

Note that only the **execute()** method of any given controller is executed.

[Module overview]({{page.baseurl}}/architecture/archi_perspectives/components/modules/mod_intro.html)

group: architecture-guide

title: Module conventions

menu_title: Module conventions

Modules must conform to Magento conventions regarding code location and file names. Keep these conventions in mind when working with or developing modules.

Be sure to research additional Magento conventions, beyond those applicable to modules. For more information, see [Coding Standards]({{page.baseurl}}/coding-standards/bk-coding-standards.html).

The following table shows the *recommended* location within the Magento file system for specific components.

(A [module](https://glossary.magento.com/module) must include a `registration.php` file in its root folder.)

We refer to a component's root directory as the top-level directory in which you develop component code. Typically, this directory is located in one of the following directories relative to the Magento root directory:

|Entity|Location|

|---|---|

|Code base of your custom module|`/app/code/<Vendor>/<Module>`|

|Custom theme files (storefront)|`/app/design/frontend/<Vendor>/<theme>`|

|Custom theme files (modules)|`<Module>/<theme>`|

|If you want to use a library|`/lib/<Vendor_Library>`|

group: architecture-guide

title: Module dependencies

menu_title: Module dependencies

A *software dependency* identifies one software component's reliance on another for proper functioning. A core principle of Magento architecture is the **minimization of software dependencies**. Instead of being closely interrelated with other modules, modules are optimally designed to be *loosely coupled*. Loosely coupled modules require little or no knowledge of other modules to perform their tasks.

Each Magento [module](https://glossary.magento.com/module) is responsible for a unique feature. In practice, this means that:

* Several modules cannot be responsible for one feature.

* One module cannot be responsible for several features.

* Module dependencies on other modules must be declared explicitly. You must also declare any dependency upon other components (for example, a theme, language package, or library).

* Removing or disabling a module does not result in disabling other modules.

There are two types of Magento {% glossarytooltip c1e4242b-1f1a-44c3-9d72-1d5b1435e142 %}module{% endglossarytooltip %} dependencies: hard and soft.

A module with a *hard dependency* on another module cannot function without the module it depends on. These modules: