Is it useful to categorize modules? Would it make Magento easier to understand? I have been working with the tech writers recently on the Magento 2 documentation and how to get concepts across in the clearest way possible which got me thinking about how to describe modules in a better way than a flat list of over a hundred descriptions to read through one by one.
A goal of Magento 2 is to put even more focus on its modular architecture, to reduce coupling between modules, and just make it easier to put together a site with only the functionality you want. I don’t know if it is a good name, but I have been playing with the name “site developer” to represent a developer who selects the set of modules to include on a site.
System Integrators frequently perform this role for Merchants, but there are certainly Merchants who do this internally as well. So I was after a term that captured a “role” rather than a job title. People often play different roles in their company. “Site Developer” appeals to me to go along with an “Extension Developer” who implements modules that can be added to a site.
I can reel off the architectural concepts that an extension developer needs to know: blocks, layouts, controllers, service contracts, etc. But what are the architectural concepts a “site developer” needs to know? Well, they should know of three types of components (modules, themes, and language packs). But there are over a hundred of them on a standard site, most of which are modules. So is there a better categorization scheme than a flat list?
Here is a possible categorization scheme. (These categories also form a conceptual layering of a site. Upper layer components ideally should only refer down to components at a lower layer.)
- Site Branding Components: These components make a site yours. Your logos, your look and feel, your tweaks to HTML to make your site look distinctly yours. Themes would normally be at this level, but also modules that did site specific reconfiguration would also sit at this level.
- Extensions: These are third party extensions you have decided to include on your site. They are not specific to your site, but not shipped with Magento. They may extend or replace parts of a default Magento installation.
- Add-on Components: These modules are designed to plug-in and extern Core Components (below). For example, Magento_Shipping is a core module that accepts multiple add-on modules Magento_Usps, Magento_Ups, Magento_Fedex, and Magento_Dhl.
- Core Components: These are core e-commerce site functionality modules like Customer, Product, Sales, Shipping, and so forth. All core components ideally would define a service contract, allowing the default implementation to be replaced with a different implementation.
- Infrastructure Components: (A better name may be “Framework Components”, although I do not consider them to be a part of “The Framework”.) These are components that do not provide direct e-commerce functionality but are needed to construct a site. The main reason they are modules and not a part of “the Framework” (below) is all web interactions must be done via modules. Examples include theme management support (Magento_Theme), and admin UI support (Magento_Backend).
The following are not a part of what a Site Developer is responsible for, but represent two layers that can be drawn under the component layer.
- The Framework: This should not really be listed with the above. It is a series of libraries used to the support the implementation of components. It includes PHP code under \Magento\Framework, and also assets such as a “UI Library” (LESS files for standard Magento CSS styling, which would typically be extended by “Site Branding Components” above).
- Third Party Libraries: These sit under “The Framework” and represent libraries such as Zend Framework, Symphony, ImageMagick, jQuery, and so on.
Turning it into a diagram might look something like this.
What do you think? Is the role of a “site developer” a useful concept to you? If so, what architectural concepts do you think they are concerned with? Is the above categorization of modules useful? Do you have better names or descriptions of categories?
Please use the wonderful invention of a “comments” box below to leave your opinion. Thanks!