Spryker Core Module Redefined

Denis Turkov

From the 2nd version of Spryker Commerce Framework, the commerce products (B2B, B2C, B2B MP, B2C MP, Unified Commerce) based on the framework had high level of module granularity. You can find modules like Category, CategoryStorage, CategoryPageSearch, CategoryDataImport, CategoryDataExport, CatalogPage etc. This was a good way to install only functions you need, reduce integration, upgrade and maintenance on your project.

Now this is going to change.

In such a module group we may easily spot the domain-defining module - Category, and its satellites (or sub-modules), which may extend the domain with sub-domains (according to DDD) or its technology stack (UI, API, P&S etc).

From now on we want to group stable sub-domains and technologies in a single domain module.

This will group modules, based on real-use patterns learns from hundreds of Spryker projects (which modules consumed, extended and customised together), and therefore:

• reduce dependencies
• reduce maintenance efforts, based on the real-use patterns
• reduce upgrading efforts
• reduce dev efforts, and less IDE folder jumps
• and many more cools things.

Presentation layer modules remain outside in most of the cases: Yves and GUI modules.

As this change is cooking in our product teams, I would like to listen to your opinion.

• How the new modules with this approach will change your project DX?
• How the old refactored modules (eg Product, …) will change your project DX?

PS. A few terms

• DX - DevX, or Developer Experience
• Spryker Core Module - the modules you find your ./vendor/spryker folder, we also call them SCOS product modules.