Module Structure in Magento MSI

Theory of Operation

Magento 2 is a highly modular system which provides possibilities for extension and customization on many levels. The modular design of the system composed of separate components (modules) that can be connected together. The beauty of modular architecture is that you are able to replace or add any component (module) without affecting the rest of the system. Replaceability (interchangeability) was one of the main reasons behind introducing Service Layer in Magento 2, as utilizing Service Contracts and providing extension over them, 3rd party developers could enhance out of the box business logic or replace one without breaking the system and other extensions relying on these contracts.

In Magento 2 you will usually see the service contract of a module defined by a set of interfaces in the module’s /Api directory, so that Magento module brings both APIs and implementation for these APIs. A module interface expresses the elements (Entity interfaces and Services to manipulate them) that are provided and required by the module. The elements defined in the interface are detectable by other modules, and represent a gateway for communication with the module. The implementation contains the working business logic that corresponds to the elements declared in the interface.

But placing Service Contracts (API), Implementation and UI in the same module we combine different layers of the system in the scope of one component. So that there could be different scenarios and reasons for extension/customization which would affect different layers of the system, for example, to customize UI 3rd party dev would still need to customize the same module as if he would like to substitute implementation for out-of the-box business logic. Even if a developer needs to provide fully custom own UI - he/she would still end up having out-of-the-box UI in the module, it's just not possible not to have it in the codebase, even if developer no need it at all (i.e. usage Magento in a headless way).

Desirable State of Modularity

Having a good modular architecture means to have loose coupling between components of the system, preserving an ability not to depend on the components which are not needed for particular deployment. To provide a switchability for modules of the system, we need to follow the single responsibility principle on the level of Magento modules. So that every module should have responsibility over a single part of the functionality and all its services should be narrowly aligned with that responsibility.

Applying SRP to module responsibilities taking into account multi-layered architecture of Magento we end-up having independent modules responsible for:

• Service Contract APIs
• Implementation of business logic for APIs
• UI. In case of Magento 2 it makes sense to segregate AdminUI and FrontendUI, as it's possible to have 2 different stacks of technology for admin ui and front-end ui
  • AdminUI (using UI components)
  • FrontendUI (using PWA studio stack of technology React/Redux)

So, instead of having 1 module covering some business domain, we create 4 modules each one responsible for a dedicated layer of the system to provide high granularity for customizations.

Here you can see MSI modules created following this principle

Such approach implies additional limitations to code inside the modules:

• All the modules should depend on the API module, while implementations could be easily swapped via di.xml
• API modules are allowed to contain Web API tests inside, as these tests cover APIs endpoints agnostically to the implementation details. Example of InventoryApi\Tests\Api\*
• Only UI modules are allowed to contain MFTF tests inside, as these tests cover interraction of user with UI of the system. Example of InventoryCatalogAdminUi\Test\Mftf\*

MSI modules structure

For Magento MSI, such modules deviation is very useful, because there are a lot of ways how Magento could be integrated with ERP. In many integrations (especially for big merchants), ERP system considered as a source of truth for order processing and inventory manipulations happen there as well. The ERP provides own UI for managing Stock per Source and Product level. This is even true for Magento Order Management which is equipped with own UI. In such case, to provide an ability of Inventory management both in ERP and Magento is excessive, as that would lead to sophisticated bi-directional synchronization of changed data. That's why it makes sense to switch off Inventory management UI in Magento at all and stay with UI provided by ERP. That's easy to do that having dedicated modules responsible for Admin and Frontend UI.

That's why we always consider two ways of MSI usage:

• Using Magento UI
• Headless way (Using UI of external system)

For Headless Magento usage (without Admin UI) MSI is dependent on API of next Magento 2.3 modules:

• Catalog
• Sales
• CatalogInventory(legacy)
• Store
• ConfigurableProd
• GroupedProd
• BundleProd
• EAV
• ImportExport

For Non Headless (including Admin UI part) case, Magento MSI will have additional dependencies on:

• UI
• Backend
• Reports
• Directory
• Shipping