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.
Site Developers
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.
Site Architecture
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.
Wrapping Up
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!
Alan Kent's Blog 
I like the approach here of breaking down the components into different areas, apart from anything else I think it could have a role to play in explaining which areas of magento an extension is aimed at which would help in decision making when looking to buy extensions potentially. For instance we could have this type of diagram on Connect and then for each extension highlight in which hexagon(s) it sits. It would be good if we could differentiate between ‘alters’ and ‘replaces’.
I think naming is always a personal thing, you just need to be careful with ensuring people on 1.x can transition to 2.x. Right now everything below extensions down to the framework is now called core, so just be careful that that is understood that this changes in 2 if you are reusing core to just mean core components.
If you are going with using 3rd party libraries as term, and then framework (which I think should be called Magento framework btw), then you should ensure the codebase reflects this structure. In my mind this would mean under lib you have a 3rd party directory and then the magento directory. Right now in 2 its not like this and I think that would need tidying. Then the concepts all map to ‘real’ life.
In terms of the use of the word extensions I think you need to be very careful here, as extensions can really sit at any of these layers. To give some examples of extns and where they fit:
– Logger – this is an infrastructure component
– Email – again infrastructure really (though I suspect you could argue core)
– Matrixrates Shipping Carrier – add on component
– Dropship – core component
– Shipping from WSA – Potentially a core component if we switch off the current one (which I hope will be possible)
– Swatch – site branding component (I know now in core magento but you get the idea)
– Advanced custom options – sites as an extension, but also touches on core component and potentially site branding
I like the approach OroCRM made of splitting out the platform from the product. In an ideal world it would be good if Magento could do that, I think you are nearly there with it in the above, seems to me every upto and including the Infrastructure components is the platform, and above that you have Magento the commerce solution. The platform is really pretty static, the product Magento is much open to manipulation.
Anyhow just brainstorming, I havent really thought about it massively, but thats my immediate feedback. Thanks for sharing your thoughts Alan, I think I speak for many in that we respect you greatly for sharing your ideas and asking for feedback.
Okay so we just recorded Episode 12 and I did kind of a horrible job of overviewing this article and giving some comments on it, so I figured it was high time I wrote something down.
—
Yes, agree with Karen that it’s awesome to see you share your thoughts here as they’re developing and get feedback from the community.
Also agree with Karen that classifying extensions may be problematic. I think there are more extensions that *cut across* components than those that sit neatly *within* a component.
Infrastructure components – This is crazy but before I got to the poll section at the bottom, I had written out this in my comment that I was about to post:
Maybe you could have Core Components vs. Core Commerce Components.
But then again since this is an ecommerce framework, there are going to be certain core components (Mage_Customer) that are core to the application and the application can’t work without them. So they really are *core* components, not just core commerce components.
Side note: I just noticed that you included MageMail in the diagram! Nice!!!
*Site Developer Role*
I think that the categorization of site developer vs. extension developer is kind of interesting. It’s probably better than having no categorization at all. But the idea of a site developer mostly just plugging modules together feels a bit theoretical to me.
In my experience at least, when I’m in that “site developer” role, I’m constantly moving between installing modules, customizing them, fixing issues in them, modifying them (putting my Extension Developer hat on I suppose you could say), gluing them together with other parts of the site, etc.
And sometimes even while doing purely “site development” work, I’ll realize that something I’m working on could be open sourced, so I’ll build it out as a community module. Some of my best community extensions have come out organically while doing “site development” work.
That said, in the ecosystem, companies do break down pretty neatly into those that do site development and those that do extension development. So maybe there is something there.