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.

mohammedalama

As someone with experience in Core Commerce development and a strong interest in Domain-Driven Design (DDD), I have a specific concern about the proposed module reorganization Regarding REST API Integration in Domain Modules:
I question the inclusion of REST API components within the domain modules. Here's why:

• Separation of Concerns:
  REST APIs, like GUI modules, represent external communication interfaces
  They are essentially adapters to the outside world, similar to BackendGUI/Page/Widget components
  These interfaces should ideally be decoupled from core domain logic
• Proposed Alternative Structure:
  The domain module should primarily focus on:
  Core domain logic
  Data storage
  Search functionality
  Import/Export capabilities (as these are tightly coupled with domain data structure)
• External Communication Layer:
  REST APIs could be extracted to a separate communication layer along with:
  GUI modules
  Backend interfaces
  Other external-facing components
  This approach would better align with DDD principles by maintaining clearer boundaries between the domain core and its external interfaces, while still preserving the benefits of the proposed module consolidation for core domain functionality.