You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main technical concept we follow in MSI architecture is to segregate Command and Query APIs. In our case, the role of Query APIs plays StockItem related interfaces and services as the StockItem entity is an aggregated indexed data among the physical locations (Sources)plus additional business rules on top of it so that StockItem data is calculated based on the raw data we have on Source level. A customer working with front-end does not update StockItem data directly, he just exposes commands which would be processed by the system later.
The similar principle should be applied for StockItem configuration as well so that Front-end would work with StockItem configuration only which is built based on SourceItem configuration. But the things here are a bit more complicated than in comparison to stock availability and salable quantity calculation because there are different configuration options and some of them could be specified on the level of Source, others on the level of Stock. Thus, the process of Indexation and Aggregation data for StockItemConfiguration indexes would be more sophisticated as it should apply own corresponding business rules to build and store each particular Config Option.
The main technical concept we follow in MSI architecture is to segregate Command and Query APIs. In our case, the role of Query APIs plays StockItem related interfaces and services as the StockItem entity is an aggregated indexed data among the physical locations (Sources)plus additional business rules on top of it so that StockItem data is calculated based on the raw data we have on Source level. A customer working with front-end does not update StockItem data directly, he just exposes commands which would be processed by the system later.
The similar principle should be applied for StockItem configuration as well so that Front-end would work with StockItem configuration only which is built based on SourceItem configuration. But the things here are a bit more complicated than in comparison to stock availability and salable quantity calculation because there are different configuration options and some of them could be specified on the level of Source, others on the level of Stock. Thus, the process of Indexation and Aggregation data for StockItemConfiguration indexes would be more sophisticated as it should apply own corresponding business rules to build and store each particular Config Option.
https://github.com/magento-engcom/msi/wiki/Stock-and-Source-Configuration-design
The text was updated successfully, but these errors were encountered: