url: /architecture/archi_perspectives/ABasics_intro.html

children:

- label: Architectural diagrams

url: /architecture/archi_perspectives/arch_diagrams.html

- label: Architectural layers

url: /architecture/archi_perspectives/ALayers_intro.html

children:

- label: Presentation layer

url: /architecture/archi_perspectives/present_layer.html

- label: Service layer

url: /architecture/archi_perspectives/service_layer.html

children:

- label: Module overview

- label: Modules and areas

url: /architecture/archi_perspectives/components/modules/mod_and_areas.html

- label: Module relationships

url: /architecture/archi_perspectives/components/modules/mod_relationships.html

- label: Module dependencies

url: /architecture/archi_perspectives/components/modules/mod_depend.html

children:

- label: Development environment recommendations

include_versions: ["2.1"]

url: /config-guide/prod/development-environment.html

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.

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`).

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

Although Magento architecture favors loosely coupled software components, modules can contain dependencies upon these software components:

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

Note: You can lose the historical information contained in a module if the module is removed or disabled. We recommend alternative storage of module information before you remove or disable a module.

At a high level, there are three main steps for managing module dependencies:

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

The Magento Framework provides a set of core logic: [PHP](https://glossary.magento.com/php) code, libraries, and the basic functions that are inherited by the modules and other components.

A module is a directory that contains the PHP and [XML](https://glossary.magento.com/xml) files (blocks, controllers, helpers, models) that are related to a specific business feature, such as Shipping. Specifically, a Magento module is composed of these software components: [themes]({{page.baseurl}}/frontend-dev-guide/themes/theme-overview.html), [libraries]({{page.baseurl}}/architecture/archi_perspectives/third-party-libs.html), and [language packages]({{page.baseurl}}/frontend-dev-guide/translations/xlate.html#m2devgde-xlate-languagepack).

Modules typically live in the `vendor` directory of a Magento installation, in a directory with the following PSR-0 compliant format: `vendor/<vendor>/<type>-<module-name>`, where `<type>` can be one of the following values:

For example, the Customer Import/Export module of Magento can be found at `vendor/magento/module-customer-import-export`.

Inside this folder, you will find all the code related to this module, including the `etc/module.xml` file, which contains the name and version of the module, as well as any dependencies.

Magento developers, administrators, and anyone building a Magento website will want to review all relevant topics surrounding their particular goals and use cases.

menu_title: Domain layer

The [domain](https://glossary.magento.com/domain) layer holds the business logic layer of a Magento [module](https://glossary.magento.com/module). It typically does not contain resource-specific or database-specific information. Its primary functions include:

* Defining the generic Magento data objects, or models, that contain business logic. This logic defines which operations can be performed on particular types of data, such as a Customer object. These models contain generic information only. Applications can also use SOAP or RESTful endpoints to request data from models.

* (Optionally) Including the implementation of service contracts, although not their definition.

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

**Best practice:** Use service contracts to communicate with the domain layer by passing data types through strongly typed objects. This helps you avoid the need to replace presentation layer code when replacing business layer logic.

Each domain-layer model contains a reference to a resource model, which it uses to retrieve data from the database with MySql calls. This resource model contains logic for connecting to the underlying database, typically MySQL. A model requires a resource model only if the model data must persist.

There are three primary ways of accessing a module's domain-layer code:

* Domain layer code in one module can also plug itself into another module by:

Your strategy for calling another module's domain-layer code is highly dependent upon the unique configuration and needs of your system.