Com certeza, para quem vem do desenvolvimento do Magento 1, uma das grandes mudanças que irá notar quando iniciar o desenvolvimento em Magento 2 será em sua arquitetura, desde a organização das pastas em que se instalavam módulos no Magento 1, até ao fato de ser necessário compilar seu código. Neste artigo abordaremos a parte de estrutura Back-end Magento 2.
Ao contrário do Magento 1, que seguia a estrutura MVC, os desenvolvedores do Magento 2 não utilizam essa estrutura e também não intitulam uma outra estrutura, embora se pareça muito com Model, View, View e Model (MVVM).
É seguido o padrão PSR-4 no desenvolvimento do Magento 2 e a mesma deve ser seguida quando se desenvolve um módulo, sendo uma boa prática recomendada pela própria Magento e que também o seu código melhor.
O Magento 2 usa o ObjectManager para gerar e injetar as classes declaradas em seu construtor. No artigo ObjectManager e compilação em Magento 2 falamos um pouco mais sobre o que é o ObjectManager…
Estrutura de pastas principais
<sua instalação Magento>/app
: Esse é o local recomendado para o desenvolvimento de componentes.
– para módulos use a pastaapp/code
;
– para os temas de front-end, use a pastaapp/design/frontend
;
– para os temas de admin, use a pastaapp/design/adminhtml
;
– para os pacotes de linguagem, use a pastaapp/i18n
.<sua instalação Magento>/vendor
: Todos os componentes de terceiros (e o próprio Magento) são baixados e armazenados no diretóriovendor
. Esta pasta é padrão pelo Composer e toda alteração que for necessário para um código desta pasta, deve ser feita na pastaapp/code
, nunca navendor
.<sua instalação Magento>/pub
: Os arquivos de front (javascript, phtml, css…) estarão compilados nesta pasta. É esta pasta que seu servidor web irá ler.<sua instalação Magento>/var
: Já conhecida de muitos, aqui estão arquivos que seu Magento irá salvar temporariamente, como cache, logs, reports… No Magento 2, um outro diretório que será criado dentro da pastavar
é a pastageneration
em que será criado todos os Factories das suas classes, geradas pelo ObjectManager.
Adeus pastas community, local!
Não há mais distinção na pasta app/code
entre módulo community e local, agora todos os módulos ficam dentro dessa pasta e também ganham uma outra novidade: os arquivos de front também ficam dentro da pasta de cada módulo (css, javascript, phtml …). Abaixo um exemplo da pasta app/code
com alguns módulos instalados.

Registrando Model, Block, Helper…
No Magento 1 era comum a estrutura abaixo para se declarar as models, blocks, helpers… O que era bem trabalhoso e que podia trazer muita dor de cabeça para depurar.

Mas como o Magento 2 utiliza o conceito de Dependency Injection e namespaces 🙏, isso não é mais necessário. Todo o conteúdo que estiver dentro da pasta do seu módulo será compilado via compilador do Magento e este será o responsável por injetar essas classes.
Estrutura de um módulo
Uma estrutura típica de um módulo em Magento 2 segue este padrão:
Block
: Contém os blocos de seu módulo;Controller
: Contém os controllers (MVC) do seu módulo;Model
: Contém os models (MVC) do seu módulo;Setup
: Contém classes para estrutura de banco de dados de módulos e configuração de dados que são invocados ao instalar ou atualizar.etc
: Contém arquivos de configuração, sendo a única pasta obrigatório para um módulo;i18n
: Contém os arquivos de tradução do seu módulo;view
: Contém arquivos de exibição, incluindo arquivos estáticos (css, js), templates, modelos de e-mail e arquivos de layout.
Como podemos ver, algumas partes sofreram atualizações (no caso da pasta etc
) ou receberam novas estruturas como por exemplo a pasta Plugin
que é uma novidade e será comentada em outra publicação.
Vale notar que um arquivo obrigatório de todo módulo é o registration.php
, nele você declara o seu módulo para o Magento 2. Este arquivo possui a seguinte estrutura:

E outro arquivo que todo módulo possui é o arquivo composer.json
(não confundir com o arquivo da raiz do projeto) em que você declara quais dependências esse módulo possui entre outras configurações.
Dentro de etc
também temos um arquivo obrigatório para todo módulo, que especifica a versão de seu módulo, o arquivo module.xml
, como exemplo abaixo:

A pasta etc
também pode ser dividida em outras partes, como no exemplo em que há arquivos para a pasta etc/adminhtml
, em que estas configurações se aplicarão apenas ao painel administrativo do Magento e etc/frontend
em que tais configurações se aplicam ao front do Magento.
Habilitando/Desabilitando um módulo
No Magento 1 cada módulo possuía seu respectivo arquivo xml, dentro da pasta app/etc/modules
, para registro em que você declarava a qual codepool pertencia e etc… No Magento 2 todos os módulos são habilitados ou desabilitados no arquivo app/etc/config.php
dentro de um array. Abaixo temos um exemplo desse arquivo:

Também podemos habilitar ou desabilitar um módulo através da linha de comando, com os comandos:
bin/magento module:enable --clear-static-content
Vendor_Name
bin/magento module:disable --clear-static-content
Vendor_Name
Para não estender muito, criei um outro artigo sobre a Estrutura básica de um módulo em Magento 2 para quem tiver curiosidade.
E, para saber mais sobre a estrutura de um módulo em Magento, sugiro a leitura da documentação oficial do Magento 2 (en-US) neste link e neste link
Local.xml
Outro ponto estrutural com mudanças é a configuração no banco de dados e outras configurações, que deixou de ser um arquivo xml (o famoso arquivo app/etc/local.xml
no Magento 1) para um arquivo php e toda a configurações fica dentro de um array no arquivo app/etc/env.php
.
Muito bom!